Wydział Odlewnictwa Wirtualizacja technologii odlewniczych Projektowanie systemów zarządzania
Treść wykładu Cykl Ŝycia systemu SDLC Metody stosowane w SDLC Metodyki alternatywne 2
Cykl Ŝycia SI System Development Life Cycle (SDLC) - standardowa metoda rozwijania SI, zakładająca sekwencyjne (ale zachodzące na siebie) wykonanie następujących etapów: 1. analiza istniejącego systemu 2. zdefiniowanie wymagań 3. projektowanie 4. opracowanie nowego systemu lub zakup 5. wdroŝenie 6. działanie operacyjne 7. ocena działania systemu 8. utrzymanie i konserwacja Wynikiem kaŝdego etapu moŝe być zatrzymanie prac lub powrót do któregoś z wcześniejszych etapów. 3
Cykl Ŝycia SI Dlaczego nie zawsze się udaje UŜytkownik nie umie wyartykułować swoich potrzeb. Próba wdroŝenia nierealnego projektu. Niedopasowanie poszczególnych części systemu. Opracowanie i wdroŝenie systemu informatycznego jest duŝym przedsięwzięciem organizacyjnym. 4
Cykl Ŝycia SI Dlaczego nie zawsze się udaje Autor programu nigdy nie przetestuje go wiarygodnie. Nie ma programów bezbłędnie działających, są co najwyŝej niedostatecznie przetestowane. Prawa Weilera obsługi i konserwacji oprogramowania: KaŜdy działający program jest przestarzały. JeŜeli program jest uŝyteczny, to będzie musiał być zmieniany. Pełną dokumentację mają tylko programy bezuŝyteczne. ZłoŜoność programu rośnie odwrotnie proporcjonalnie do zdolności programisty ten program konserwującego. Drugie prawo Weinberga: Gdyby budowlani budowali domy w taki sam sposób, w jaki programiści piszą programy, to jeden dzięcioł zniszczyłby całą cywilizację. 5
Cykl Ŝycia SI 6
Cykl Ŝycia analiza istniejącego systemu Celem badania jest określenie czy istniejący system spełnia wyznaczone cele i zadania organizacji. Badanie wykonuje specjalnie powołany zespół, którego skład zaleŝy od wielkości organizacji. Zespół jest odpowiedzialny za opracowanie raportu oceniającego potrzebę analizy i zaprojektowania systemu. Decyzję o dalszych pracach podejmuje kierownictwo organizacji. Analiza ma wskazać problemy i ograniczenia istniejącego systemu oraz określić, w jaki sposób rozszerzyć system, by spełniał cele i zadania organizacji: wybór zespołu zebranie danych analiza danych przygotowanie raportu 7
Cykl Ŝycia analiza istniejącego systemu NaleŜy połoŝyć nacisk na silne i słabe strony istniejącego systemu przetwarzania danych. NaleŜy przede wszystkim określić: wejścia i wyjścia systemu, kartoteki (zbiory), ich zawartość i sposoby przechowywania, zasady współdziałania uŝytkowników, metody i procedury przetwarzania danych, działający sprzęt i oprogramowanie. 8
Cykl Ŝycia analiza istniejącego systemu Zbieranie danych: techniki wywiady (kierowane i swobodne) kwestionariusze przykładowe dokumenty bezpośrednie obserwacje rozmowy telefoniczne testy statystyczne symulacja 9
Cykl Ŝycia analiza istniejącego systemu Analiza danych ma za cel przetworzenie surowych danych w formę dostosowaną do oceny istniejącego systemu. M. in. naleŝy określić: największy, najmniejszy i średni poziom aktywności uŝytkowników, redundancję procedur, operacje najbardziej pracochłonne, operacje, które wymagają duŝych nakładów obliczeniowych, procedury, które stały się zbędne. 10
Metody projektowania i analizy systemów Podejście systemowe (strukturalne) Narzędzia i techniki charakteryzujące się podejściem topdown, w którym uŝytkownicy analizują system począwszy od duŝego stopnia uogólnienia i stopniowo go uszczegółowiają. 11
Metody projektowania i analizy systemów Podejście systemowe (strukturalne) Diagram kontekstowy (Context Diagram) Graficznie opisuje ogólną budowę systemu; Diagramy przepływu danych (DFD - Data Flow Diagrams) Przedstawia funkcjonowanie podsystemów, DFD pokazuje 3 czynniki: w jaki sposób dane przepływają przez system (wejścia i wyjścia), procesy przetwarzania danych, gdzie dane są zapamiętywane i przechowywane. Opis danych: diagram związków encji (ERD); Opis procesów: wykresy przepływów w systemie (system flowchart), drzewa decyzyjne, tablice decyzyjne. 12
Metody projektowania i analizy systemów Analiza procesów - tablice decyzyjne Reguła nr Warunek 1 2 3 4 5 6 7 8 9 1. Ile dni upłynęlo od terminu zapłaty? poniŝej 14 T N N T N N T N N 15-30 N T N N T N N T N powyŝej 30 N N T N N T N N T 2. Kwota naleŝności poniŝej 1000 zł T T T N N N N N N 1001-5000 zł N N N T T T N N N powyŝej 5000 zł N N N N N N T T T Decyzja 1. wysłać wezwanie do zapłaty X X X X X X X X 2. zawiadomić komórkę rewindykacji X X X 3. wstrzymać kredytowanie powyŝej 1000 zł X 4. wstrzymać kredytowanie w ogóle X 13
Cykl Ŝycia zdefiniowanie wymagań Celem tego etapu jest odpowiedź na pytanie: co i w jaki sposób będzie robił system. System powinien rozwiązać problemy wykryte w etapie I. Wymagania organizacyjne: wejścia, magazynowanie danych, przetwarzanie i wyjścia. Wymagania wpływające na oprogramowanie i sprzęt. Oszacowanie moŝliwych wariantów. Opracowanie raportu. 14
Cykl Ŝycia projektowanie systemu Ogólny projekt sytemu powinien zawierać: uwarunkowania organizacyjne określenie funkcji systemu projekt wyjść projekt procedur przetwarzania projekt wejść projekt zbiorów i baz danych UŜywane techniki 15
Cykl Ŝycia opracowanie nowego systemu Przegląd wymagań oprogramowania pod względem wejść, wyjść i przetwarzania Opracowanie logiki programu Zakodowanie programu Przetestowanie programu Udokumentowanie programu 16
Cykl Ŝycia wdroŝenie systemu Opracowanie dokumentacji operacyjnej Przeszkolenie uŝytkowników Przekształcenie zbiorów danych Przetestowanie systemu Praca z nowym systemem 17
Cykl Ŝycia wdroŝenie systemu Podejście Opis WdroŜenie równoległe WdroŜenie bezpośrednie Stary i nowy system funkcjonują równolegle, aŝ nowy zacznie odpowiednio działać Kosztowne, ale bezpieczne Najlepsze dla krytycznych podsystemów Nowy system natychmiast zastępuje stary Mniej kosztowne, ale bardziej ryzykowne Najlepsze dla niekrytycznych podsystemów 18
Cykl Ŝycia wdroŝenie systemu Podejście Opis WdroŜenie pilotaŝowe WdroŜenie etapowe Jedna z jednostek jest polem doświadczalnym Najlepsze dla średniokrytycznych podsystemów Elementy nowego systemu stopniowo zastępują elementy starego Bezpieczne i konserwatywne podejście Najlepsze dla krytycznych podsystemów 19
Cykl Ŝycia ocena i utrzymanie systemu Określenie czy system spełnia oczekiwania uŝytkowników Utrzymanie (konserwacja) systemu: poprawianie błędów, niewielkie zmiany w funkcjonowaniu, regularna aktualizacja. 20
Inne metodyki rozwijania systemów SDLC szczególnie dobrze sprawdza się w projektach, gdzie uŝytkownicy mają jasno sprecyzowane wymagania. Alternatywą lub raczej uzupełnieniem SDLC mogą być nowe metodyki rozwijania oprogramowania jak: prototypowanie, Joint application design (JAD) czy Extreme Programming (XP). Prototypowanie - metodyka tworzenia systemów, która polega na tworzeniu i ocenie prototypów czyli roboczych modeli systemu. 21
Pakiety oprogramowania aplikacyjnego UŜywane przez firmy, które nie mają doświadczenia lub potrzeby rozwoju systemu jako całości. Dobre dla niekrytycznych aplikacji takich jak: word processing, analizy finansowe, ewidencja magazynowa czy kadrowa. Z reguły pakiety te wymagają dostosowania (ang. customization) do specyfiki firmy. 22
Pakiety oprogramowania aplikacyjnego Gotowe pakiety z minimalnymi zmianami 49% Tworzone na zamówienie 26% Bd 2% Gotowe pakiety z duŝymi zmianami 23% 23
Pakiety oprogramowania aplikacyjnego Kluczowym elementem sukcesu w tej metodzie jest dokładne sprecyzowanie wymagań odnośnie cech, jakie musi spełniać oferowane oprogramowanie. Porównanie róŝnych ofert pozwoli wybrać to, które w największym stopniu spełnia nasze wymagania. 24
Systemy tworzone przez uŝytkowników Rozwój systemów przez uŝytkowników końcowych z małym lub nawet bez formalnego wsparcia specjalistów-informatyków. Pozwalają uŝytkownikom na uwzględnienie swoich specyficznych potrzeb biznesowych. Podejście właściwe w przypadku małych podsystemów, nie przetwarzających masowych transakcji. 25
Outsourcing Praktyka polegająca na zlecaniu obsługi informatycznej i telekomunikacyjnej do usługodawców zewnętrznych. Dokonywane ze względów ekonomicznych lub technicznych. Funkcje Udział DzierŜawa PC i sieci 35% Wsparcie techniczne 34% Rozwój aplikacji 30% Brak 24% Obsługa systemu 22% Konserwacja systemu 19% Inne 19% Call center 15% 26
Rozwój systemów czynniki sukcesu Wszystkie systemy informatyczne są systemami biznesowymi Wiele projektów kończy się niepowodzeniem, bo są postrzegane jako projekty techniczne, a nie biznesowe Reagowanie na zmiany W miarę zmian w otoczeniu systemu, system musi się zmieniać Rozwój systemu jest procesem ryzykownym 27
Rozwój systemów czynniki sukcesu Standardowe rozwiązania nie są wystarczające szczególnie w globalnym otoczeniu NaleŜy uwzględniać uwarunkowania techniczne, kulturowe i polityczne Zespół ds. rozwoju IS menadŝer musi zbudować zespół zdolny do twórczej, innowacyjnej i grupowej pracy UŜytkownicy Kluczowym czynnikiem sukcesu nie jest sprzęt ani oprogramowanie, lecz uŝytkownicy 28