Projektowanie systemów informatycznych

Transkrypt

1 Projektowanie systemów informatycznych 1 Metodyka i takie tam gadanie bzdur 1.1 Metodyka tworzenia SI - elementy Metodyka tworzenia systemu informatycznego - elementy Parametry Modele DP Metody i i techniki Pojcia abstrakcyjne Pakiety Reguy modelowania Fazy Dokumentacja Narzdzia komputerowego Zadania wspomagania Wspomaganie Dziedzina przedmiotowa Wyniki analiz PROCES TWORZENIA SYSTEMU INFORMATYCZNEGO System informatyczny Cele, problemy, potrzeby informatyczne Prezentacja i eksperymentalna eksploatacja Korekty i modyfikacje Akceptacja Tworzenie systemu Kierowanie projektami Kryteria oceny Zespó projektujcy ródo: S. Wrycza, Analiza i projektowanie systemów informatycznych zarzdzania. Metodyki, techniki, narzdzia, PWN, Warszawa ródªa zªo»ono±ci procesu tworzenia SI Dziedzina przedmiotowa, badany wycinek rzeczywisto±ci, obejmuj cy ogromn liczb wzajemnie uzale»nionych aspektów i problemów Zespóª projektuj cy - ograniczenia pami ci, percepcji, wyra»ania informacji i komunikacji I jeszcze 2 punktu z tego slajdu, nie bardzo wiadomo, czemu na tym dlajdzie. Modele DP, metody i itechniki, narz dzia wspomagania komputerowego warsztat analityka projektanta syste System informatyczny przekazany do oceny, a nast pnie u»ytkowania potencjalnym u»ytkownikom 1.3 Jak minimalizowa zªo»ono±? Zasada dekompozycji - rozdzielenie problemu na podproblemy (które mo»na rozpatrywa niezale»nie od siebie i niezale»nie od caªo±ci) Zasada abstrakcji - eliminacja, ukrycie lub pomini cie mniej istotnych szczegóªów rozwa»anego przedmiotu lub mniej istotnej informacji; wyodr bnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu poj lub symboli oznaczaj cych takie cechy 1

2 Zasada ponownego u»ycia - wykorzystywanie schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim wªasno±ciom - dopasowanie modeli poj ciowych i modeli realizacyjnych systemów do wrodzonych ludzkich wªasno±ci psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia ±wiata 1.4 Metodyka tworzenia systemu informatycznego - wymagania metodyka powinna obj caªy cykl»ycia systemu informatycznego metodyka powinna obejmowa ró»norodne, dostosowane do specyki podej±cia, metody, techniki i narz dzia komputerowe wspomagaj ce proces tworzenia systemu i analiz metodyka powinna uªatwia porozumiewanie si pomi dzy ró»nymi grupami zawodowymi tworz cymi SI metodyka powinna by stosunkowo ªatwa w u»ytkowaniu, powinna móc ewoluowa i podlega mody- kacjom 1.5 Klasykacja metodyk teorzenia SI Kryteria oceny metodyk: podej±cie do procesu tworzenia SI (metodyki techniczne lub spoªeczne) deniowanie danych lub procesów w projekcie (podej±cie strukturalne) oddziaªywanie SI na dziedzin przedmiotow (organizacyjne odwzorowanie, organizacyjne sterowanie) kierunek tworzenia systemów informatycznych (top-down, buttom-up) Podej±cia metodologiczne do tworzenia SI strukturalne obiektowe spoªeczne 1.6 Etapy tworzenia, wdra»ania i stabilizacji SI Zadania na poszczególnych etapach: Wst pne rozpoznanie systemu - identykacja celu, problemów, stanu obecnego i perspektyw rozwoju systemu lub jego zmian Analiza informacyjna systemu - identykacja otoczenia, ª czno±ci z otoczeniem, podsystemów, skªadowych systemu oraz obecnych i przyszªych warunków jego dziaªania Projekt systemu - stworzenie modelu obecnego lub przyszªego systemu, projekt techniczny systemu lub zmian Oprogramowanie (kodowanie) - oprogramowanie :) Wdro»enie (zastosowanie, aplikacja) - instalacja i stworzenie dokumentacji systemu oraz testowanie systemu (w wypadku niepowodzenia powrót do etapu analizy lub projektowania) Uruchomienie (realizacja) - monitoring, ocena i modykacje systemu 2

3 1.7 Cykl»ycia systemu Cykl»ycia systemu to ci g wyodr bnionych, wzajemnie spójnych etapów, pozwalaj cych na peªne i skuteczne zaprojektowanie a nast pnie u»ytkowanie systemu informatycznego. 2 Cykle (modele) 2.1 Tradycyjne cykle»ycia oprogramowania 1. Kaskadowy (klasyczny, waterfall) 2. V 3. Prototypowy 4. Spiralny 5. Przyrostowy Model kaskadowy (klasyczny, waterfall) Model kaskadowy (ang. waterfall model) jeden z kilku rodzajów procesów tworzenia oprogramowania zdeniowany w in»ynierii oprogramowania. Jego nazwa wprowadzona zostaªa przez Winstona W. Royce w roku 1970, w artykule "Managing the Development of Large Software Systems" (zarz dzanie tworzeniem du»ych systemów informatycznych). Polega on na wykonywaniu podstawowych czynno±ci jako odr bnych faz projektowych, w porz dku jeden po drugim. Klasyczny cykl ycia systemu z iteracjami ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa Ka»da czynno± to kolejny schodek (kaskada): 1. Planowanie systemu (w tym Specykacja wymaga«) 2. Analiza systemu (w tym Analiza wymaga«i studium wykonalno±ci) 3

4 3. Projekt systemu (poszczególnych struktur itp.) 4. Implementacja (wytworzenie kodu) 5. Testowanie (poszczególnych elementów systemu oraz elementów poª czonych w caªo± ) 6. Wdro»enie i piel gnacja powstaªego systemu. Je±li która± z faz zwróci niesatysfakcjonuj cy produkt cofamy si wykonuj c kolejne iteracje a» do momentu kiedy otrzymamy satysfakcjonuj cy produkt na ko«cu schodków. Wady: Nie mo»na przej± do nast pnej fazy przed zako«czeniem poprzedniej Model ten posiada bardzo nieelastyczny podziaª na kolejne fazy Iteracje s bardzo kosztowne - powtarzamy wiele czynno±ci Tego typu modelu nale»y u»ywa wyª cznie w przypadku gdy wymagania s zrozumiaªe i przejrzyste, poniewa» ka»da iteracja jest czasochªonna i wymaga du»ych wydatków na ulepszanie Model V Schemat wytwarzania wedug modelu V ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa Model prototypowy Model prototypowy tworzenia oprogramowania polega na stworzeniu podczas projektowania prototypu w celu przedyskutowania oraz akceptacji z klientem. Po akceptacji prototypu przechodzi si do kolejnych etapów tworzenia oprogramowania. Prototypowanie zapobiega bª dnym zrozumieniem wymaga«systemu, które mo»e powodowa wzrost kosztów, zwªaszcza w modelu kaskadowym. Spis tre±ci [ukryj] 4

5 Schemat prototypowania ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa Zalety prototypowania Wady Prototyp jest ªatwy do zmiany Zwi ksza zrozumienie programistów co do potrzeb klienta Pozwala klientowi zobaczy jak mniej wi cej system b dzie wygl daª W zale»no±ci od rodzaju prototypu, mo»e pozwala rozpocz szkolenie obsªugi systemu po stronie klienta Redukcja kosztów Mo»liwo± nieporozumie«z klientem (klient widzi prawie gotowy produkt, który w rzeczywisto±ci jest dopiero w pocz tkowej fazie rozwoju) Wysoki koszt budowy systemu Rodzaje prototypów Zªy system wykonany za pomoc modelu odkrywkowego, którym stosunkowo szybko si wykonuje Rozpisanie interfejsów na kartce papieru Implementacja jedynie kilku moduªów U»ycie kreatorów w celu szybszego stworzenia interfejsów Implementacja metod dziaªaj cych jedynie w wi kszo±ci przypadków lub dla niektórych danych w celu pokazanie jedynie idei. 5

6 2.1.4 Model spiralny Proces tworzenia ma posta spirali, której ka»da p tla reprezentuje jedn faz procesu. Najbardziej wewn trzna p tla przedstawia pocz tkowe etapy projektowania, np. studium wykonalno±ci, kolejna denicji wymaga«systemowych, itd. Spis tre±ci [ukryj] Ka»da p tla spirali podzielona jest na cztery sektory: Ustalanie celów - Deniowanie konkretnych celów wymaganych w tej fazie przedsi wzi cia. Identykacja ogranicze«i zagro»e«. Ustalanie planów realizacji. Rozpoznanie i redukcja zagro»e«- Przeprowadzenie szczegóªowej analizy rozpoznanych zagro»e«, ich ¹ródeª i sposobów zapobiegania. Podejmuje si odpowiednie kroki zapobiegawcze. Tworzenie i zatwierdzanie - Tworzenia oprogramowania w oparciu o najbardziej odpowiedni model, wybrany na podstawie oceny zagro»e«. Ocena i planowanie - Recenzja post pu prac i planowanie kolejnej fazy przedsi wzi cia b d¹ zako«czenie projektu. Cykl spiralny wytwarzania oprogramowania ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa Cechy Widoczn cech modelu spiralnego jest szczegóªowe potraktowanie zagro»e«realizacji projektu. Dobrze rozpoznane zagro»enia i przedsi wzi te kroki im zapobiegania lub redukcji skutkuj m.in. wysok niezawodno±ci (dependability) powstaj cego oprogramowania, b d¹ pewno±ci,»e projekt ma szanse dalszej realizacji. W modelu spiralnym nie ma takich faz jak specykowanie albo projektowanie. Jeden cykl spirali mo»e przebiega w oparciu o model kaskadowy procesu tworzenia oprogramowania, w innym mo»na u»y prototypowania lub przeksztaªce«formalnych, w zale»no±ci od aktualnego etapu przedsi wzi cia / realizowanej cz ±ci systemu (np. inny dla tworzenia interfejsu u»ytkownika, inny dla krytycznych funkcji bezpiecze«stwa) 6

7 Ka»dy cykl wymaga formalnej decyzji o kontynuacji projektu. Zalety Wady Mo»na wykorzysta gotowe projekty Faza oceny w ka»dym cyklu pozwala unikn bª dów lub wcze±niej je wykry Caªy czas istnieje mo»liwo± rozwijania projektu. Metodologia nie do ko«ca dopracowana. Ka»dy projekt jest inny i powstaje w innych warunkach. Ci»ko okre±li jakie warunki bra pod uwag. Tworzenia w oparciu o model spiralny wymaga do±wiadczenia w prowadzeniu tego typu projektów oraz cz sto wiedzy ekonomicznej w zarz dzaniu. Zastosowanie Model spiralny z racji ogólnego charakteru stosuje si przy du»ych projektach Model przyrostowy Podejcie przyrostowe ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa Fazy okre±lenie caªo±ci wymaga«(w ramach naszych mo»liwo±ci, na tyle na ile uda nam si j sprecyzowa ), wykonanie wst pnego, ogólnego projektu caªo±ci systemu wybór pewnego podzbioru funkcji systemu szczegóªowy projekt (wg modelu kaskadowego) oraz implementacja cz ±ci systemu realizuj cej wybrane funkcje 7

8 testowanie zrealizowanego fragmentu i dostarczenie go klientowi powtarzanie kolejnych etapów, a» do zako«czenia implementacji caªego systemu Zalety Wady cz ste kontakty z klientem (skrócenie przerw w porównaniu z modelem kaskadowym) brak konieczno±ci zdeniowania z góry caªo±ci wymaga«(na wst pie deniujemy co nam si uda maj c nadziej,»e uda nam si wyspecykowa caªo± wymaga«na etapie testowania zrealizowanych fragmentów) wczesne wykorzystanie przez klienta fragmentów systemu (funkcjonalno±ci) mo»liwo± elastycznego reagowania na opó¹nienia realizacji fragmentu przyspieszenie prac nad inn /innymi cz ±ciami (sumarycznie bez opó¹nienia caªo±ci przedsi wzi cia projektowego) dodatkowy koszt zwi zany z niezale»n realizacj fragmentów systemu potencjalne trudno±ci z wycinaniem podzbioru funkcji w peªni niezale»nych dlatego: konieczno± implementacji szkieletów (interfejs zgodny z docelowym systemem) dodatkowy nakªad pracy (koszt), ryzyko niewykrycia bª dów w fazie testowania Uwagi Stosuje si do przypadków, gdy dopuszczalna jest okrojona funkcjonalno± systemu. 2.2 Wspóªczesne cykle wytwarzania oprogramowania 1. Prototypowanie wytwórcze 2. Cykl wytwarzania obiektowego 3. Proces wytwarzania z wykorzystaniem zasobów ponownego u»ycia 4. Cykl»ycia systemu wedªug metodyki SSM (Soft Systems Methodology) 8

9 2.2.1 Procesy prototypowania wytwórczego P R O T O T Y P O W A N I E W Y M A G A ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa

10 2.2.2 Cykl wytwarzania obiektowego ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa ródo: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa

11 2.2.3 Zasoby ponownego u»ycia komponenty oprogramowania (jednostki monta»owe oprogramowania, których interfejsy s okre±lone na drodze umów i których kontekstowe zale»no±ci s jawne) wzorce oprogramowania (formy reprezentacji wiedzy i do±wiadczenia projektantów w postaci opisów typowych problemów wyst puj cych w tworzeniu oprogramowania oraz ich rozwi za«, które mog by wielokrotnie wykorzystywane w ró»nych okoliczno±ciach) wzorce analizy (analysis patterns) wzorce projektowe (design patterns) wzorce architektoniczne (architecture patterns) wzorce aplikacji (application frameworks) 3 Technologie wytwarzania oprogramowania strukturalna obiektowa Ogólne zasady (niezale»nie od technologii): dekompozycji modularyzacji Podej±cie techniczne (hard approaches) Cykle»ycia i wytwarzania oprogramowania bazuj ce na nast puj cych zaªo»eniach: istnieje dobrze identykowalny wycinek rzeczywisto±ci, o pewnym stanie i uporz dkowaniu, który mo»e by przedmiotem informatyzacji cele analizy i konstrukcji systemu s jasne i znane, a docelowy system jest dobrze okre±lony przej±cie od stanu aktualnego do systemu docelowego mo»e by zrealizowane ±rodkami technicznymi mo»liwe jest porównanie systemu docelowego z istniej cym, przy u»yciu miar technicznych procesy analizy i konstrukcji wykonywane s przez ekspertów. Do podej± technicznych nale» m.in. cykl kaskadowy, model spiralny, prototypowanie wytwórcze, podej±cie przyrostowe, model fontannowy, ponowne wytwarzanie. Podej±cia spoªeczne (soft approaches) zakªadaj nierozª czno± aspektów technicznych systemów informatycznych od aspektów pozatechnicznych organizacji, zarz dzania, socjologii, psychologii itd. jednym z najbardziej znanych podej± spoªecznych jest SSM (Soft Systems Methodology). 3.1 Technologia strukturalna Ogólna charakterystyka wytwarzanie oprogramowania wedªug reguª cyklu klasycznego utworzenie logicznego modelu systemu poprzedza modelowanie zyczne dominuje w latach 80-tych i na pocz tku lat 90-tych notacje graczne: diagramy przepªywu danych, diagramy przej± stanów, diagramy zwi zków encji, diagramy struktury 11

12 3.1.2 Podstawowe metody strukturalne: Modele zwi zków encji (diagramy zwi zków encji, diagramy relacyjne danych, Entity Relationship Diagrams, Entity Relationship Models) Diagramy przepªywu danych (diagram b bli, DataFlow Diagram) Sªownik/Skorowidz danych (Data Dictionary) Specykacje procesów (Process Specication) Diagramy sieci przej± (State Transition Diagram) Grafy podej±cia ISAC (Information Systems Work and Analysis of Changes) Techniki decyzyjne (tablice, drzewa decyzyjne) Diagramy struktury (Structure Charts) Konkretnie modele te s opisane na slajdach Wady i zalety technologii strukturalnej Zalety: uwzgl dnienie wszystkich podstawowych faz cyklu»ycia oprogramowania, podziaªem na fazy analizy i projektowania intuicyjno± spojrzenia na system poprzez funkcje, procesy i przepªywy danych poªo»enie nacisku na modelowanie na poziomie logicznym, i skupienie uwa dopiero w dalszej kolejno±ci na szczegóªach implementacyjnych wprowadzenie standardów w zakresie modeli i notacji gracznych wykorzystywanie narz dzi CASE Wady: wysoka pracochªonno± trudno±ci w iteracyjnym modykowaniu projektu stosowanie odmiennych modeli w fazie analizy i w fazie projektowania 3.2 Technologia obiektowa Podstawowe poj cia: Obiekt To»samo± obiektu, identykator Atrybuty i metody obiektów Polimorzm Przesyªanie komunikatów Klasy obiektów, hierarchie klas Dziedziczenie Enkapsulacja (hermetyzacja) Unied Modeling Language 12