Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00293 008579 11062419 na godz. na dobę w sumie
Analiza i projektowanie strukturalne. Wydanie III - książka
Analiza i projektowanie strukturalne. Wydanie III - książka
Autor: Liczba stron: 256
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-397-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Technologia CASE (Computer Aided System Engineering) jest obecnie od dziesięciu lat powszechnie stosowana w analizie i projektowaniu systemów informatycznych. Trudno sobie wyobrazić pracę bez niej (szczególnie przy dużych projektach) na etapie analizy, tworzenia projektu systemu czy jego implementacji.

Techniki CASE umożliwiają wspomaganie: Techniki strukturalne są w dalszym ciągu kluczowymi w projektowaniu aplikacji bazodanowych. Niniejsza książka opisuje te techniki, stosując jako egzemplifikację klasyczną metodykę Yourdona (rozkład funkcjonalny), a także metodykę SSADM oraz (w zakresie modelowania danych) metodykę Martina. Autor na podstawie swojego dziesięcioletniego doświadczenia w stosowaniu technologii CASE, odwołując się do projektów którymi kierował, przedstawia możliwości i ograniczenia prezentowanej metodyki. Na konkretnych przykładach autor uczy jak budować aplikacje na etapie analizy i projektu posługując się technikami strukturalnymi. Uzupełnieniem są załączone przykłady w formie zadań z rozwiązaniami.

Zagadnienia omówione w książce obejmują zakres tematyczny:

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Analiza i projektowanie strukturalne. Wydanie III Autor: Jerzy Roszkowski ISBN: 83-7361-397-8 Format: B5, stron: 256 Technologia CASE (Computer Aided System Engineering) jest obecnie od dziesiêciu lat powszechnie stosowana w analizie i projektowaniu systemów informatycznych. Trudno sobie wyobraziæ pracê bez niej (szczególnie przy du¿ych projektach) na etapach: • analizy, • tworzenia projektu systemu, • a tak¿e samej implementacji. Techniki CASE umo¿liwiaj¹ wspomaganie: • analizy i projektowania bazy danych, • projektowania aplikacji • generacji kodu aplikacji • automatycznego tworzenia dokumentacji analizy i projektu • in¿ynierii odwrotnej (tworzenie modeli fizycznych i logicznych aplikacji na podstawie jej kodu i fizycznej bazy danych) Techniki strukturalne s¹ w dalszym ci¹gu kluczowymi w projektowaniu aplikacji bazodanowych. Niniejsza ksi¹¿ka opisuje te techniki, stosuj¹c jako egzemplifikacjê klasyczn¹ metodykê Yourdona (rozk³ad funkcjonalny), a tak¿e metodykê SSADM oraz (w zakresie modelowania danych) metodykê Martina. Autor na podstawie swojego dziesiêcioletniego doġwiadczenia w stosowaniu technologii CASE, odwo³uj¹c siê do projektów którymi kierowa³, przedstawia mo¿liwoġci i ograniczenia prezentowanej metodyki. Na konkretnych przyk³adach autor uczy jak budowaæ aplikacje na etapie analizy i projektu pos³uguj¹c siê technikami strukturalnymi. Uzupe³nieniem s¹ za³¹czone przyk³ady w formie zadañ z rozwi¹zaniami. Zagadnienia omówione w ksi¹¿ce obejmuj¹ zakres tematyczny: • Budowy logicznych modeli danych i funkcjonalnego systemu • Przekszta³canie modeli logicznych w model fizyczny • Przekszta³canie modelu funkcjonalnego w model aplikacji • Bilansowanie modeli • Analizy systemów obiegu dokumentów • Analizy systemów budowanych z gotowych komponentów • Analizy cykli ró¿nych wytwórczych oprogramowania • Analizy i projektowania hurtowni danych Spis treści Wprowadzenie ...................................................n................................ 7 Rozdział 1. Ogólne metody analizy systemowej ...................................................n. 9 Rozkład funkcjonalny ...................................................u...................................................u.10 Model funkcjonalny — metoda przepływu danych ...................................................u.......11 Modelowanie informacji (danych) ...................................................u.................................11 Podejście obiektowe...................................................u...................................................u....12 Rozdział 2. Diagramy modelowania metodyki strukturalnej ................................. 13 Charakterystyka narzędzi modelowania ...................................................u..........................13 Trzy modele systemu ...................................................u...................................................u..14 Model funkcjonalny — diagramy przepływu danych (Datau Flow Diagrams) — metodyka Yourdona — przykłady — typowe błędy.................................................14 Elementy składowe DFD ...................................................u.........................................15 Główne zalecenia przy projektowaniu DFD...................................................u............22 Wielopoziomowe DFD ...................................................u............................................24 Rozszerzenia do DFD dla systemów czasu rzeczywistego.........................................28 Model funkcjonalny — diagramy przepływu danych (Datau Flow Diagrams) — metodyka SSADM — przykłady...................................................u............................29 Elementy składowe DFD w metodyce SSADM...................................................u......29 Model danych — diagramy obiekt-relacja-atrybut (Entity Relationship Diagrams — ERD) — metodyka Martina.....................................30 Elementy diagramu ERD ...................................................u.........................................33 Projektowanie logiczne danych — model relacyjny ..................................................39 Projektowanie logiczne danych — normalizacja danych................................................41 Zależności atrybutów ...................................................u...............................................42 Projektowanie logiczne danych — modelowanie tablic.............................................49 Mapowanie w sytuacji interpretacji subtypów przez relację wzajemnego wykluczania się...................................................u...........55 Przekształcenie modelu funkcjonalnego w projekt strukuturalny — diagramy strukturalne (STC Structured Charts) ...................................................u.....56 Model dynamiki — diagramy przejść stanów (State Transition Diagrams).....................58 Rozdział 3. Słownik danych (Data Dictionary)...................................................n.. 65 Formalizm notacji słownika danych ...................................................u..............................65 Definicje ...................................................u...................................................u......................66 Rozdział 4. Specyfikacja procesów ...................................................n................. 69 4 Analiza i projektowanie strukturalne Rozdział 5. Bilansowanie modelu ...................................................n.................... 75 Bilansowanie diagramu DFD względem słownika danych (DD)...............................76 Bilansowanie diagramu DFD względem specyfikacji procesów................................76 Bilansowanie specyfikacji procesów względem DFD i słownika danych..................76 Bilansowanie słownika danych względem DFD i specyfikacji procesów..................77 Bilansowanie ERD względem DFD i specyfikacji procesów.....................................77 Bilansowanie DFD względem diagramu przejść stanów (STD) ................................77 Rozdział 6. Cykl projektowy...................................................n............................ 81 Etap I — Studium możliwości...................................................u.................................81 Etap II — Analiza ...................................................u...................................................u.83 Etap III — Projektowanie ...................................................u........................................83 Etap IV — Implementacja ...................................................u.......................................83 Etap V — Przejście na nowy system ...................................................u.......................84 Cykle projektowe w technologiach niektórych kluczowych dostawców..........................85 Definicja potrzeb biznesowych...................................................u................................86 Analiza istniejących systemów ...................................................u................................87 Opracowanie architektury technicznej...................................................u.....................87 Projektowanie i budowa bazy danych...................................................u......................87 Projektowanie i budowa modułów...................................................u...........................87 Konwersja danych...................................................u...................................................u.88 Opracowanie dokumentacji technicznej ...................................................u..................88 Testowanie ...................................................u...................................................u............88 Szkolenie...................................................u...................................................u...............89 Przejście na nowy system ...................................................u........................................89 Obsługa serwisowa ...................................................u..................................................89 CDM — podejście klasyczne...................................................u.........................................89 Definicja...................................................u...................................................u................89 Analiza ...................................................u...................................................u..................90 Projekt ...................................................u...................................................u.................. .90 Budowa ...................................................u...................................................u.................90 Przejście ...................................................u...................................................u................91 Produkcja ...................................................u...................................................u..............91 CDM — podejście „szybkiej ścieżki” (Fast Track) ...................................................u.......91 Modelowanie wymagań ...................................................u...........................................91 Projektowanie i generowanie systemu...................................................u.....................91 Przejście do produkcji...................................................u..............................................92 CDM — podejście „Lite”...................................................u...............................................92 Prototyp i budowa ...................................................u...................................................u.93 Przejście do produkcji...................................................u..............................................93 Specyfikacja dostaw powstających w ramach przedsięwzięciua informatycznego (według metodyki CDM)...................................................u.............................................94 Dział I — Specyfikacja wymagań (Requirements Definition) ...................................94 Dział II — Przegląd istniejącego systemu (Existing system examination) ................95 Dział III — Architektura techniczna (Technical Architecture) ..................................95 Dział IV — Projektowanie i wytworzenie bazy danych (Database Design and Build) .....96 Dział V — Projektowanie i wytworzenie modułów (Module Design and Build)......96 Dział VI — Konwersja danych (Data Conversion) ...................................................u.97 Dział VII — Dokumentacja (Documentation)...................................................u.........97 Dział VIII — Testowanie (Testing)...................................................u.........................98 Dział IX — Szkolenie (Training) ...................................................u............................98 Dział X — Uruchomienie — przejście (Transition)...................................................u99 Dział XI — Wsparcie po uruchomieniu (Post-System Support) ................................99 Spis treści 5 Rozdział 7. Studium możliwości (Feasibility Study) ........................................... 101 Zapoczątkowanie projektu ...................................................u...........................................101 Wybór przedsięwzięcia ...................................................u................................................101 Fazy realizacji ...................................................u...................................................u.....103 Sporządzanie analizy opłacalności ...................................................u........................105 Rozdział 8. Proces analizy ...................................................n............................ 107 Podejście klasyczne — cztery modele systemu ...................................................u...........107 Model podstawowy systemu ...................................................u........................................110 Model otoczenia ...................................................u...................................................u........110 Model zachowania się systemu ...................................................u....................................112 Zasady prowadzenia wywiadów ...................................................u..................................115 Formularz hierarchii operacji ...................................................u.......................................116 Formularz wzorów dokumentów ...................................................u.................................117 Rozdział 9. Analiza systemu obiegu dokumentów ............................................. 119 Formularz i semantyka opisu obiegu dokumentów...................................................u......119 Model i jego konkretyzacja ...................................................u..........................................120 Struktura modelu...................................................u...................................................u.121 Wizualizacja modelu...................................................u..............................................130 Rozdział 10. Analiza systemu budowanego z gotowych komponentów ................. 141 Definicja istniejącej struktury organizacyjnej — (regulamin organizacyjny)..........141 Definicja struktury organizacyjnej...................................................u.........................142 Kluczowy personel jednostki...................................................u.................................142 Grupy użytkowników wewnątrz organizacji ...................................................u.........142 Obiekty (organizacje) zewnętrzne ...................................................u.........................142 Zakres analizy w układzie głównych procesów biznesowych — lista obszarów tematycznych (Context process model) ....................................142 Prototypy podstawowych obiektów informacyjnych, w tym bazy normatywnej globalnej i lokalnej ...................................................u....143 Inwentaryzacja zasobów osobowych oraz technicznych (infurastruktury i oprogramowania) — istniejąca architektura techniczna ......................................143 Przegląd architektury ...................................................u.............................................143 Struktura sieci ...................................................u...................................................u.....144 Środowisko programowe (software)...................................................u......................144 Analiza procesów biznesowych istniejącego systemu informacyjnego ...................144 Ogólny model koncepcyjny rozwiązania docelowego...................................................u.145 Model warstwowy systemu zarządzania...................................................u................145 Model przypadków użycia docelowego systemu informatycznego .........................145 Model docelowy danych (model logiczny danych) ..................................................145 Bilansowanie obszarów tematycznych z gotowymi aplikacjami..............................146 Bilansowanie przypadków użycia obszaru tematycznego i aplikacji .......................147 Bilansowanie modelu logicznego danych z zakresem danych aplikacji ..................149 Rozdział 11. Analiza i projektowanie testów...................................................n.... 151 Rodzaje i techniki testów ...................................................u.............................................153 Testy regresyjne ...................................................u...................................................u..154 Testy operacyjne ...................................................u...................................................u.154 Testy pełnozakresowe (przy pełnym obciążeniu systemu).......................................154 Testy wydajnościowe...................................................u.............................................155 Testy negatywne ...................................................u...................................................u.155 Testy ergonomiczne ...................................................u...............................................155 Testy dokumentacji użytkownika końcowego...................................................u.......155 Testy akceptacyjne (α-testy i β-testy)...................................................u....................156 6 Analiza i projektowanie strukturalne Dodatek A Zastosowanie metod strukturalnych w projektowaniu hurtowni danych...................................................n......157 Niedostatki systemów wspomagania decyzji oraz hurtownie udanych jako usuwające je — koncepcje zmian...................................................u......................157 Architektura i funkcje hurtowni danych...................................................u.......................160 Repozytorium metadanych ...................................................u....................................162 Technologia bazy danych hurtowni danych ...................................................u..........163 Narzędzia zapytań, raportowania i analizy oraz narzędzia „data mining” ...............163 Administracja i zarządzanie hurtownią danych ...................................................u.....164 Struktura hurtowni danych ...................................................u...........................................165 Warianty architektury technicznej hurtowni danych ...................................................u...166 Wirtualna hurtownia danych...................................................u..................................166 Architektura wielu składnic danych...................................................u.......................168 Architektura hurtowni z dostępem tylko do składnic danych...................................169 Architektura hurtowni z dostępem mieszanym...................................................u......171 Przykładowa specyfikacja tematycznych hurtowni danych............................................173 Hurtownia danych w zakresie analizy i planu sprzedaży .........................................173 Hurtownia danych w zakresie analizy, planu i rozliczenia produkcji ......................174 Hurtownia danych w zakresie analizy kosztów ...................................................u.....176 Przykładowe specyfikacje tematyczne systemów wspomaganiua decyzji opartych na hurtowniach (aplikacje klienta w technologii klient-serwer)...................................177 Aplikacje klienta obsługujące hurtownie danych ...................................................u..177 Dedykowane systemy klasy DSS oparte na hurtowniach danych ............................178 Specyfikacja cyklu projektowego dla hurtowni danych .................................................179 Określenie funkcji zarządzania wspieranych przez hurtownie.................................180 Dokumentowanie istniejących w przedsiębiorstwie systemów transakcyjnych.......181 Doprowadzenie do spójności metadanych pomiędzy systemami transakcyjnymi przedsiębiorstwa.............................................181 Specyfikacja wymagań systemów DSS oraz aplikacji klienta obsługujących hurtownie danych ...................................................u........................181 Projektowanie hurtowni danych ...................................................u............................182 Specyfikacja mapowania i transformacji danych ...................................................u..182 Narzędzia do analizy i projektowania...................................................u....................182 Cykl realizacji ...................................................u...................................................u.....183 Dodatek B Zadania...................................................n...................................... 187 Zadanie 1. — Diagramy przepływu danych i związków encji (ERD) .....................187 Zadanie 2. — Diagramy przepływu danych i związków encji (ERD) .....................189 Zadanie 3. — Diagramy związków encji (ERD) ...................................................u...190 Zadanie 4. — Diagramy związków encji (ERD) ...................................................u...190 Zadanie 5. — Diagramy związków encji (ERD) ...................................................u...191 Zadanie 6. — Diagramy związków encji (ERD) ...................................................u...192 Zadanie 7. — Studium możliwości...................................................u........................193 Zadanie 8. — Zarządzanie marketingiem i kontrola procesu wytwórczego ............195 Zadanie 9. — Diagram obiegu dokumentów...................................................u.........195 Zadanie 10. — Projekt modelu logicznego hurtowni danuych w zakresie analizy sprzedaży ...................................................u..............................197 Zadanie 11. — Projekt modeli logicznych kostek informuacyjnych hurtowni danych w zakresie analiz finansowych i kosztów w przedsiębiorstwie .....198 Dodatek C Rozwiązania...................................................n................................ 207 Literatura ...................................................n................................... 247 Skorowidz...................................................n................................... 249 Rozdział 6. Cykl projektowy Wprowadzone w poprzednich rozdziałach narzędzia modelowania wykorzystuje się na różnych etapach cyklu projektowego. Są trzy podstawowe cele wprowadzenia pojęcia cyklu eprojektowego:  aby zdefiniować czynności w procesie budowy systemu,  aby wprowadzić i utrzymać spójność pomiędzy wieloma preojektami w tej samej organizacji,  aby wprowadzić punkty kontrolne w zarządzaniu projeketem na różnych etapach jego rozwoju. Na rysunku 6.1 przedstawiono etapy klasycznego cyklu projektowego, najczę- ściej definiowane podczas budowy systemu. Etap I — Studium możliwości Zazwyczaj zaczyna się od zapytania użytkownika, czy można zautomatyzować jeden albo więcej elementów jego działalności. Głównymi przyczynami wprowadzenia studium możliwości są:  identyfikacja ludzi odpowiedzialnych za określenie ccelu systemu; prowadzi to do ustalenia szeregu interview, w wyniku których zostanie to sprecyzowane oraz zdefiniowany zostanie początkoewy diagram kontekstu.  identyfikacja wad i niedostatków aktualnego systemu informatycznego- -informacyjnego; składa się z listy funkcji, których brakuje lub nie esą wykonywane właściwie przez istniejący system. 82 Analiza i projektowanie strukturalne Rysunek 6.1. Klasyczny cykl projektowy stosowany w analizie strukturalnej  ustalenie celów i ograniczeń nowego systemu; może to być także prosta lista istniejących funkcji systemu, które muszą być zaeimplementowane ponownie, nowych funkcji, które muszą być dodane oraz elista kryteriów, które musi spełniać nowy system.  określenie wykonalności systemu z podaniem kilku scenariuszy; powinien być określony harmonogram, koszt budowy nowego systemue oraz uzyskane korzyści. Zazwyczaj proponuje się kilka arcehitektur dla wdrożenia systemu, na przykład przetwarzanie scentralizowane e(mainframe), przetwarzanie rozproszone, architektura klient-serwer etc.  określenie lidera projektu (project manager); studium możliwości zajmuje na ogół od 5 do 10 całego czasu trwania projektu. Rozdział 6. ♦ Cykl projektowy 83 Etap II — Analiza Głównym celem etapu analizy jest wprowadzenie strukturalnej specyfikacji opi- su projektu za pomocą narzędzi modelowania wprowadzonych w poprzednich rozdziałach, tzn. diagramów przepływu danych — DFD, diagramów obiekt- -relacja-atrybut — ERD, diagramów przejść stanów — STD. Rezultatem analizy jest zbudowanie następujących modeeli:  model otoczenia,  model zachowania systemu. Modele te omówiono w rozdziale 7. Są one opisem formalnym systemu, nie- zależnym od technologii, jakiej użyje się do implemeentacji nowego systemu. Na końcu etapu analizy określa się dokładniej niż w poprzednim etapie budżet projektu oraz kalkulację kosztów i zysków. Etap III — Projektowanie Etap ten przeznaczony jest też do budowy tzw. modelu implementacji użytkow- nika, która powinna zawierać:  wyodrębnienie tych części modelu zachowania systemu, które będą implementowane w systemie informatycznym,  przydzielenie poszczególnych części specyfikacji do eodpowiednich procesorów lub serwerów (przetwarzanie rozproszone). eWycięte fragmenty DFD (te, które będą implementowane) są mapowane na zadaneia (tasks) — tu interfejsu użytkownika końcowego,  zaprojektowanie struktury hierarchii modułów wewnąterz danego zadania, jak to opisano w podrozdziale „Przekształcenie modeleu funkcjonalnego w projekt strukturalny — diagramy strukturalne (STC Steructured Charts)”. Ponadto podczas etapu projektowania należy dokonać teransformacji diagramów ERD na relacyjną bazę danych (projektowanie elogiczne danych), tak jak to opisano w podrozdziale „Model danyech — diagramy obiekt-relacja-atrybut (Entity Relationship Diagrams — ERD) e— metodyka Martina”. Etap IV — Implementacja Etap ten składa się z kodowania i integracji modułów. Stosuje się techniki pro- gramowania strukturalnego oraz implementacji top-down. 84 Analiza i projektowanie strukturalne Etap V — Przejście na nowy system Podczas tego etapu wykonuje się następujące czynnoścei:  testy akceptacyjne systemu zapewniające jego właściewą jakość,  konwersję bazy danych przy przejściu ze starego systeemu na nowy,  instalację. W ostatnich latach rozpowszechnia się inny cykl budowy aplikacji spełniający wymagania wielowarstwowej architektury klient-serwer. Cykl ten schematycz- nie przedstawiono na rysunku 6.2. Ten cykl życia stosuje iteracyjne prototypo- wanie aplikacji w fazie analizy, a następnie przynosi szereg przyrostowych dostaw. Rysunek 6.2. Przyrostowy cykl życia projektu informatycznego, uwzględniający wymagania budowy aplikacji w technice obiektowej Rozdział 6. ♦ Cykl projektowy 85 Każdy przyrost odpowiada zaimplementowaniu pojedynczego USE CASE (przy- padku użycia) lub zbioru przypadków użycia pojęć, wprowadzonych w meto- dyce obiektowej Jacobsona analizy i projektowania. [Jacobson-94]. Iteracyjne prototypowanie aplikacji jest także często stosowane z zastosowa- niem technik strukturalnych. Cykle projektowe w technologiach niektórych kluczowych dostawców Kluczowi dostawcy oprogramowania opracowali własne cykle wytwórcze bę- dące wewnętrznymi standardami tych firm. Przykładem może być tu Oracle Custom Development Method (CDM) [CDM-Oracle-1996]. Metodyka ta sto- suje się do tych procesów biznesowych i funkcji, które nie mogą być obsłużo- ne za pomocą dostępnych aplikacji „z półki”. CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które zostały określone przy założeniu, że w procesie wytwórczym stosujemy metody i narzędzia CASE. Metodyka ta zakłada, że potrzeby biznesowe zo- stają wyraźnie zdefiniowane na samym początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas całego proceesu wytwórczego. Stosowanie CDM znacznie zwiększa prawdopodobieństwo pozytywnego za- kończenia wdrożenia, ponieważ w wyniku stosowania tej metodyki otrzymu- jemy aplikacje zgodne z celami i potrzebami klientae. CDM określa zdefiniowane zadania (tasks) i dostawy (deliverables), z których składa się pełen cykl projektowy. Każde zadanie wytwarza jedną zdefiniowa- ną dostawę (produkt). Zadania przyporządkowane są do procesów. Każdy z pro- cesów składa się z wielu zadań Każdy z procesów jest realizowany w określonej fazie wytwórczej (lub w wielu fazach). Zakończenie konkretnej fazy odpowiada osiągnięciu odpowiednich celów i tzw. „kamieni miloewych”. Każde ze zdefiniowanych zadań może się rozpocząć pod warunkiem dostarcze- nia wykonawcy dostaw wynikających z zadań poprzedzających. Dostawy te muszą być dostępne, zanim rozpocznie się praca nad przedmiotowym zada- niem. Zależności pomiędzy zadaniami oraz pomiędzy dostawami i zadaniami pozwalają kierownikom projektów podczas procesu planowania pracy określić skutki wykluczenia lub zmiany dostawy. Struktura metodyki CDM opiera się zatem na metodologii budowy systemów opartej na zdefiniowanych procesach. 86 Analiza i projektowanie strukturalne Proces w tej metodyce określa się jako spójny zbiór albo jako ciąg powiąza- nych ze sobą zadań, których wykonanie to określony wcześniej cel projektu. Rezultatem wykonania procesu jest jedna lub więcej dostaw. Można rozumieć proces jako podprojekt wewnątrz większego projektu. Pełny cykl projektowy składa się z wielu procesów. Większość procesów zachodzi na siebie czasowo i są one powiązane pomiędzy sobą poprzez wspólne doestawy. W metodyce CDM wyróżnia się następujące procesy:  definicja potrzeb biznesowych (studium możliwości),  analiza istniejących systemów,  opracowanie architektury technicznej,  projektowanie i budowa bazy danych,  projektowanie i budowa modułów,  konwersja danych,  opracowanie dokumentacji technicznej,  testowanie,  szkolenie,  przejście na nowy system,  obsługa serwisowa. Definicja potrzeb biznesowych Definicja potrzeb biznesowych określa wymagania biznesowe co do aplikacji końcowej. Zespół analityków buduje najpierw model procesów biznesowych, zawierający wszystkie zdarzenia biznesowe i reakcje na nie, które musi wspie- rać aplikacja. Następnie zespół ten buduje model danych biznesowych repre- zentujący potrzeby informacyjne oraz model funkcji biznesowych, w którym podane są szczegóły funkcji biznesowych wskazanych perzez model procesów. Gdy tylko potrzeby biznesowe zostają zdefiniowane, ten sam zespół anality- ków dodaje do modeli wymagania technologiczne, takie jak interfejs użytkow- nika, czas odpowiedzi itd. W ten sposób zespół przekształca modele wymagań biznesowych na modele wymagań systemowych. Rozdział 6. ♦ Cykl projektowy 87 Analiza istniejących systemów Istotnym wymaganiem w wielu budowanych projektach jest zastąpienie funk- cjonalności istniejących systemów lub też praca nowego systemu w istniejącej architekturze technicznej. Proces analizy istniejących systemów spełnia te wy- magania. Wiele z zadań w tym procesie może być usuniętych, jeśli projekt nie jest tylko funkcjonalnym zastąpieniem istniejącego esystemu. Proces analizy istniejących systemów można znacznie przyspieszyć, jeśli dys- ponujemy techniczną dokumentacją istniejącego systeemu. Opracowanie architektury technicznej Proces ten określa elementy techniczne opracowywanego projektu. Przyjmuje się, że istnieje większość informacji zgromadzonych w fazie analizy. Są one podstawą do opracowania początkowej wersji architektury technicznej. Zespół analityków przekształca tę dostawę w dwa opracowania, „Definicja sprzętu i oprogramowania” (Hardware and Software Definition) oraz „Architektura roz- proszona” (Distribution Architecture). W tym procesie powinny też zostać okre- ślone warunki dla bezpieczeństwa systemu oraz operacji backup (wykonywania kopii zapasowych) i recovery (odzyskiwania danych). Ostatnią dostawą w tym procesie jest opracowanie planu obciążenia (wydajności) przetwarzania i prze- syłania oraz składowania danych przez system. Projektowanie i budowa bazy danych Proces projektowania i budowy bazy danych rozpoczyna się wykonaniem za- dania „Projektowanie logiczne bazy danych” i kończy wygenerowaniem bazy produkcyjnej. Proces budowy relacyjnej bazy danych uwzględnia budowę sche- matu, projektowanie i budowę indeksów. Wygenerowana baza fizyczna używa Planu wydajności i Planu przetwarzania oraz Architektury rozproszonej jako podstawowych wejściowych dostaw. Projektowanie i budowa modułów Projektowanie i budowa modułów to główna część metodyki CDM. Projektanci używają Modelu procesów systemowych, Modelu danych systemowych oraz Modelu funkcji systemowych razem z architekturą techniczną do zaprojektowa- nia pierwszej wersji architektury systemu oraz do opracowania procesu Model modułów. Następnie są specyfikowane funkcjonalne techniczne szczegóły każ- dego modułu. W dalszej kolejności programiści używają tej dokumentacji pro- jektowej i prototypów modułów do budowy kodu aplikacji. Stosuje się często 88 Analiza i projektowanie strukturalne podejście iteracyjne dla każdego obszaru funkcjonalnego. Bardzo złożone apli- kacje mogą wymagać pełnej dokumentacji technicznej, zanim rozpocznie się programowanie. Konwersja danych Celem procesu konwersji danych jest opracowanie zasad migracji, konwersji i testowania danych z dotychczasowych systemów. Dane te są konieczne do te- stowania oraz do pracy nowej aplikacji. Pierwszym krokiem w tym procesie jest określenie, jakie dane powinny być skonwertowane, w podziale na odpo- wiednie źródła. Dane te mogą być potrzebne do testowania systemu, testów integracyjnych, szkolenia, testów akceptacyjnych, jak również do bieżącego przetwarzania. Dlatego też zespół projektowy musi określić ogólną strategię, aby spełnić te wymagania. Strategia ta powinna uwzględniać równocześnie me- tody automatyczne i ręczne konwersji. Proces konwersji danych zawiera w sobie projektowanie, kodowanie i testowanie każdego koniecznego modułu konwersji danych. Opracowanie dokumentacji technicznej Proces opracowania dokumentacji technicznej dotyczy produkcji wysokiej ja- kości tekstowych dostaw zawierających dokumentację użytkownika końcowe- go, dokumentację techniczną i dokumentację szkolenia dla przedmiotowego pro- jektu. Dwoma podstawowymi dokumentami są tu „Podręcznik użytkownika” (User Guide) oraz „Podręcznik funkcjonalności systemu” (User Reference). Pierwszy z nich (User Guide) oparty jest na modelu procesów systemowych w ujęciu modułów (Module Process Model). Jest on pomocą dla użytkownika w użyciu aplikacji w zakresie wykonania procesów biznesowych. Drugi (User Reference) specyfikuje funkcjonalność każdego modułu apleikacji. Testowanie Proces testowania określa zintegrowane podejście do testowania jakości wszyst- kich elementów aplikacji. W jego zakres wchodzą: testowanie modułów, testo- wanie integracyjne modułów, testy integracyjne całego systemu i testy akcepta- cyjne. Istotne jest opracowanie wspólnego planu wszystkich testów. Zaleca się użycie iteracyjne skryptów do testowania na coraz większych porcjach syste- mu aplikacyjnego. Rozdział 6. ♦ Cykl projektowy 89 Szkolenie Celem procesu szkolenia jest wykreowanie użytkowników i administratorów, którzy są odpowiednio szkoleni w celu sprawnego wykonywania zadań obsługi nowej aplikacji. Może być również szkolony personel, który w przyszłości będzie miał za zadanie utrzymanie systemu, oraz zespół obsługi testów akcep- tacyjnych. Przejście na nowy system Opracowanie zasad przejścia na nowy system zaczyna się dość wcześnie w fa- zach projektowania przez zdefiniowanie specyficznych wymagań dotyczących rozpoczęcia eksploatacji nowego systemu. Produkty tego procesu to „Plan in- stalacji” i „Określenie środowiska i otoczenia eksploatacji”. Obsługa serwisowa Są cztery cele obsługi serwisowej, którą prowadzi sieę po wdrożeniu systemu:  monitorowanie i reakcja na problemy za pośrednictweme help desk,  naprawa błędów oraz rozwiązywanie problemów dotycząceych wydajności przetwarzania (upgrade)  ocena systemu podczas przetwarzania użytkowego,  planowanie zmian w systemie.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Analiza i projektowanie strukturalne. Wydanie III
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: