PROJEKTOWANIE INFORMATYCZNYCH SYSTEMÓW ZARZĄDZANIA

Prezentacja na temat: "PROJEKTOWANIE INFORMATYCZNYCH SYSTEMÓW ZARZĄDZANIA"— Zapis prezentacji:

1 PROJEKTOWANIE INFORMATYCZNYCH SYSTEMÓW ZARZĄDZANIA
Prof. zw. dr hab. Witold Chmielarz

2 ETAPY ROZWOJU SYSTEMÓW INFORMATYCZNYCH
Wstępne rozpoznanie systemu (planowanie systemu) Polega na przeprowadzeniu i udokumentowaniu całościowej lub wyrywkowej obserwacji organizacji, identyfikacji i wyborze wariantu modelu systemu informacyjnego odpowiadającego sytuacji danej firmy. Wybrany model systemu informacyjnego może charakteryzować się: powieleniem sytuacji panującej w firmie, założeniem określonych, zgodnych z kierunkiem rozwoju firmy modyfikacji, dokonaniem krańcowych przeobrażeń - restrukturyzacji procesów organizacji. W każdej z tych możliwości wstępnie zostają określone informacyjne potrzeby przyszłego użytkownika oraz cele, ograniczenia, podstawowe wymagania, sporządzony rachunek ekonomiczny dla różnych wariantów rozwoju systemu. Rezultatem wstępnego rozpoznania systemu jest początkowa koncepcja (założenia) systemu. Etap wydzielany często jedynie ze względów pragmatycznych np. jako: potrzebny do realizacji zmian organizacyjnych, przed właściwie pojętą informatyzacją w tradycyjnym sposobie tworzenia systemu, zdobycia materiałów do zdefiniowania założeń programowych w procedurze przetargowej.

3 WSTĘPNE ROZPOZNANIE SYSTEMU - ETAPY
Przeprowadzenie obserwacji organizacji i wybór optymalnego dla niej rodzaju systemu Budowa koncepcji wstępnej: zdefiniowanie problemu do rozwiązania i warunków działania w trakcie realizacji (o co tu chodzi, co zostanie przez to rozwiązane, kto to będzie wykonywał i dlaczego, kto to będzie popierał, a kto przeciwnie w organizacji, a kto w otoczeniu?), określenie ogólnych potrzeb informacyjnych (kto, co, kiedy, gdzie, dlaczego, w jaki sposób, jak długo, z jaka częstotliwością, za pomocą jakich podstawowych dokumentów?), określenie celów systemu (po co w ogóle i w poszczególnych dziedzinach ma być stworzony system?), identyfikacja ograniczeń (wewnętrznych - wynikających wprost z organizacji; zewnętrznych - wynikających z otoczenia organizacji - parametry ekonomiczne i przepisy ogólne), skonstruowanie kryteriów oceny systemu, badanie wykonalności systemu (odpowiednio organizacyjnej, ekonomicznej, technologicznej i psychologicznej).

4 KRYTERIA OCENY SYSTEMU
organizacyjne użyteczność - procent pokrycia funkcji użytkowych organizacji, stopień wykorzystania przez personel, stopień integracji organizacji, ekonomiczne koszty - operacyjne, eksploatacyjne, jednostkowe, efekty - organizacyjno-ekonomiczne, zyski - szybkość i miara zyskowności, technologiczne czas - reakcji, dostępu, przetwarzania, dokładność - częstość i ilość błędów oraz istotność błędów, niezawodność - stabilność, trwałość, integralność, bezpieczeństwo - niezawodność, legalność, sekretność działania, jakość - wygląd zewnętrzny, tolerancja błędów, elastyczność - wrażliwość, zmienność, wydajność - przetwarzanie w jednostce czasu, psychologiczne stopień akceptowalności przez pracowników, potencjalne bariery wdrożeń, potencjalne metody usuwania zagrożeń systemu.

5 KOSZTY I NAKŁADY Koszty i nakłady na:
koncepcję, analizę, projektowanie systemu, przygotowanie organizacyjne i szkolenia, oprogramowanie systemowe, narzędziowe, użytkowe, zakup urządzeń podstawowych i towarzyszących i ich instalację, roboty budowlano-montażowe oraz adaptacje lub modernizację pomieszczeń, instalacje energetyczno-oświetleniowe oraz sprzęt wentylacyjno-klimatyzacyjny, położenie okablowania budynków itp. Wśród kosztów bieżących analizuje się przeważnie elementy następujące: koszty na eksploatację systemów: płace pracowników zatrudnionych bezpośrednio przy eksploatacji systemów i kadry kierowniczej, koszty przygotowania baz danych, dokumentów i innych środków, koszty testowania, dokumentacji, szkolenia bieżącego i inne koszty wdrożenia, koszty eksploatacyjne: amortyzacji, materiały eksploatacyjne, obsługi technicznej w tym: z zewnątrz, obsługi użytkowej, koszty przygotowania i kontroli danych, bezpośrednie koszty przetwarzania, koszty utrzymania urządzeń w gotowości do pracy (prąd, oświetlenie, ogrzewanie itp.), koszty ryzyka: koszty zaburzenia funkcjonowania w procesie przetwarzania (przestoje z powodów technicznych i wynikłe stąd straty), koszty początkowych błędów w instalacji systemu, straty z powodu poprawek zainstalowanych modułów systemu na życzenie klienta.

6 POTENCJALNE EFEKTY Z INFORMATYZACJI
wzrost płac lub zysków (jeżeli płace zależą od zysków) zmniejszenie kosztów przetwarzania danych zmniejszenie uciążliwości pracy zmniejszenie kosztów eksploatacyjnych zmniejszenie niezbędnych nakładów inwestycyjnych wzrost zdolności przetwórczych i efektywności pracy zahamowanie przyrostu zatrudnienia przyspieszenie ściągania należności zwiększenie możliwości przetwarzania, przekrojów informacji i wykonywanych na tej podstawie analiz polepszenie obsługi klienta redukcja błędów wzrost morale personelu usprawnienie procesu podejmowania decyzji

7 OCENA EKONOMICZNA INWESTYCJI INFORMATYCZNYCH
okres zwrotu kapitału - ocena szybkości zwrotu kapitału poniesionego na projekt inwestycyjny stopa zwrotu z inwestycji - stosunek efektów z eksploatowanego systemu do kosztów jego budowy i eksploatacji, w określonym czasie wewnętrzna stopa zwrotu - stopa dyskontowa równoważąca koszty inwestycji i przyszłe efekty zaktualizowana wartość netto - zdyskontowana wartość netto różnicy między nakładami a efektami z zastosowania systemu informatycznego Stopa zwrotu z inwestycji IT = Zyskt/Kosztt*Dt gdzie: Dt - współczynnik dyskonta w okresie t, t - czas

8 ZAŁOŻENIA INFORMATYZACJI – końcowy dokument fazy wstępnej
Zagadnienia wprowadzające Postawienie problemu do rozwiązania i określenie warunków działania Sprecyzowanie celu działania Oszacowanie ograniczeń, efektów, kosztów i potencjalnych zysków Przewidywane bariery i priorytety działania 2. Charakterystyka opisowa systemu Prezentacja stanu obecnego Przedstawienie obecnego i przyszłego zapotrzebowania na informację Wymagania w stosunku do sprzętu, oprogramowania i personelu Ekonomiczna ocena alternatywnych działań 3. Plan rozwoju przedsięwzięcia Przybliżony harmonogram i plan finansowy przedsięwzięcia Techniki analiz i gromadzenia danych Podział zadań pomiędzy wykonawców i podwykonawców Określenie metod kontroli realizacji 4. Podsumowanie i wnioski końcowe Synteza propozycji Szczegółowy harmonogram działań organizacyjnych w najbliższym czasie

9 ANALIZA INFORMACYJNA SYSTEMU- fazy
Analiza i wyciągnięcie wniosków z koncepcji wstępnej - rozwinięcie tez wynikających z pierwszego stopnia rozpoznania systemu Analiza organizacyjna systemu - szczegółowe badanie całej organizacji i jej poszczególnych elementów Analiza zasadniczych podsystemów organizacji - wg kryterium złożoności problemów lub częstotliwości rejestracji zdarzeń w organizacji i ich rutynowości oraz powtarzalności i częstotliwości wykonywanych czynności Analiza obecnego systemu informacyjnego - polegająca na dokładnym zbadaniu dokumentów i ich obiegu w organizacji oraz punktów decyzyjnych i ich wpływu na organizację Analiza proponowanego zapotrzebowania informacyjnego oraz konsekwencji z niego wynikających Sprecyzowanie wymagań informacyjnych proponowanego systemu, nowego obiegu dokumentacji, wizualizacji dokumentów oraz procesów jakie za sobą pociąga nowy obieg dokumentacji. Analiza koncepcji wstępnej zależy od jej zawartości, stopnia dokładności z jaka została wykonane, czasokresu, który dzieli wykonanie koncepcji wstępnej i analizy oraz od bieżących potrzeb analityka prowadzącego rozpoznanie systemu. Analizę organizacji przeprowadza się zaś na ogół według zamieszczonego poniżej schematu.

10 SCHEMAT ANALIZY ORGANIZACYJNEJ
Genealogia organizacji, przedstawienie jej stanu obecnego i perspektyw rozwoju Analiza porównawcza rozwoju organizacji z innymi organizacjami podobnego typu i podobnej wielkości w kraju i za granicą Określenie wpływu otoczenia organizacyjno-prawnego na organizację (regulacje rządowe, ustawy itp.) Zdefiniowanie celów, dróg dojścia do tych celów oraz strategii ich osiągnięcia Określenie polityki działania firmy w praktyce Ocena zasobów, produktów i usług niezbędnych w działaniu organizacji Przedstawienie struktury organizacyjnej i systemu zarządzania organizacją Zdefiniowanie głównych zasad działania Przedstawienie obecnego systemu informacyjnego Ukazanie przyszłego systemu informacyjnego, niezbędnych zmian organizacyjnych, jego wymagań oraz dróg dojścia do stanu docelowego

11 RAPORT "ANALIZA ORGANIZACYJNO-INFORMACYJNA"
Charakterystyka systemu - jest to przedstawienie systemu oraz jego powiązań z innymi systemami, celów jego działania, ograniczeń i kryteriów oceny. Opis dokumentów wejściowych - a zwłaszcza sprecyzowanie w każdym z nich: źródła informacji, formatu i wyglądu dokumentu, organizacji przesyłania dokumentu, objętości (najniższej, przeciętnej, najwyższej) częstotliwości pojawiania się, ilości tworzonych kopii, przeznaczenia każdej kopii, kodów i metod konwersji danych (jeżeli występują), mediów przekazu. Opis dokumentacji wyjściowej - przedstawiany jak wyżej ze szczególnym uwzględnieniem postaci dokumentów i jej zgodności zobowiązującymi przepisami

12 RAPORT "ANALIZA ORGANIZACYJNO-INFORMACYJNA"
Określenie procedur przetwarzania danych - zasadniczo oznacza przyporządkowanie dokumentów wyjścia dokumentom wejścia oraz regułom transformacji (algorytmom przetwarzania), umiejscowionym w określonym harmonogramie częstotliwości na poszczególnych stanowiskach roboczych. Dotyczy też przyporządkowanie stanowiskom konkretnych dokumentów, funkcji oprogramowania, sprzętu, personelu, urządzeń pomocniczych i specjalistycznych. Określenie procedur przesyłania danych - sprecyzowanie sieci przesyłani danych, topologii sieci, mediów przesyłania danych, dodatkowych urządzeń wspomagających transfer w sieci Organizacja gromadzenia danych - sprecyzowanie zawartości i rozmiaru baz danych ich lokalizacji, rodzajów i częstotliwości dostępu, postaci i szczegółowej struktury rekordów bazy danych, typu bazy danych (scentralizowana - rozproszona), itp. Kontrola działania systemu - określenie mechanizmów kontroli poprawności wprowadzania danych wejściowych, samego procesu przetwarzania danych i poprawności działania założonych algorytmów oraz danych wyjściowych (cyfry kontrolne), ocena mechanizmów zabezpieczeń i ich wizualizacji, relacja tego systemu w stosunku do elastyczności i adaptacyjności systemu.

13 TWORZENIE PROJEKTU TECHNICZNEGO SYSTEMU
Tworzenie projektu zgodnie z wnioskami płynącymi z analizy systemu lub przeprojektowanie organizacji systemu w razie wystąpienia takich potrzeb. Fazy: Weryfikacja założeń systemu - tworzona na podstawie dotychczasowych działań - polega na uszczegółowienie założeń wstępnych oraz analizy organizacyjno-informacyjnej systemu na poziomie dokumentu Projekt logiczny - polegający na stworzeniu deskrypcyjnego modelu logicznego systemu. Istnieją tu dwie potencjalne metody działania: stworzenie modelu ogólnego działania organizacji i modelu mechanizmów uszczegółowienia działania systemu w wyniku tworzenia kolejnych aplikacji, opracowanie modelu szczegółowego poszczególnych aplikacji i modelu interfejsu łączącego ze sobą aplikacje szczegółowe Projekt fizyczny - kreacja modelu formalnego w ostatecznej technicznie postaci (oprogramowanie, sprzęt, organizacja, rodzaj sieci itp.) Specyfikacja systemu - utworzenie pełnej dokumentacji projektowej

14 PROJEKT LOGICZNY A FIZYCZNY
Projekt logiczny - jest uszczegółowieniem wymagań systemu - przełożeniem na odwzorowanie bliskie programistom systemu ogólnego opisu organizacji, analizą alternatywnych rozwiązań (o ile występują) przepływu danych i metod ich przetwarzania; zejście na poziom dokumentu przetwarzanego na konkretnie określonym stanowisku pracy, uzgodnionego z potencjalnym użytkownikiem (w sensie nadawcy i odbiorcy dokumentu) lub stworzeniem mechanizmów jego odwzorowania. Projekt fizyczny - ustalenie „do końca” technicznej postaci systemu, zejście na poziom rekordu i pola w rekordzie w bazie danych odzwierciedlającej dokumenty cyrkulujące w systemie, szczegółowe określenie wejść, wyjść, miejsc i środków gromadzenia danych, transferu danych w ramach systemu i poza nim, wyposażenia oraz niuansów jego obsługi, niezbędnych przedsięwzięć organizacyjnych i szkoleniowych.

15 ZAWARTOŚĆ PROJEKTU TECHNICZNEGO
Charakterystyka ogólna systemu - jego cele działania, ograniczenia, struktura, schemat logiczny przepływów danych (schemat blokowy lub inne metody) Specyfikacja oprogramowania - zalecenia dotyczące oprogramowania dla systemu. Specyfikacja mediów obsługi danych - dokładna postać i obsługa formatek ekranowych, dokumentów wejściowych i wynikowych, raportów itp. Specyfikacja obsługi bazy danych - określenie w sensie: struktury, zawartości, organizacji, środków, dystrybucji, organizacji dostępu, trybu porozumiewania się, algorytmów przetwarzania danych, metod aktualizacji danych, zabezpieczeń itp. Specyfikacja transferu danych - określenie topologii sieci, mediów przesyłu danych, formatu przepływu oraz urządzeń towarzyszących Wyszczególnienie sprzętu komputerowego i innych dodatkowych urządzeń technicznych - charakterystyka komputerów i sprzętu uzupełniającego wraz z lokalizacją, opisem połączeń i dostępu do bazy danych Rozmieszczenie i wymagania względem personelu Specyfikacja wdrożenia - wnioski dotyczące instalacji i szkolenia przyszłych użytkowników systemu, harmonogram wdrożenia i szkoleń

16 NASTĘPNE FAZY ROZWOJU SYSTEMU
Oprogramowanie systemu Polega na napisaniu programów opisujących działanie systemu (zakodowanie algorytmów w konkretnym języku oprogramowania), połączenie programów w system (utworzenie struktury systemu), ewentualne dołączenie narzędzi rozwijających możliwości wykorzystania całego systemu zgodnie ze specyfikacją projektu technicznego systemu. Testowanie systemu Napisane programy, w zależności od języka programowania, systemu bazy danych itp. są sprawdzane pod względem poprawności programowej, a następnie wstępnie testowane przeważnie przez analityków ze strony poprawności logicznej i odporności na błędy końcowego użytkownika, integracji funkcjonalnej systemu itp. Instalacja systemu Jeżeli system wdrażany jest w całości wraz ze sprzętem to następuje instalacja nowego sprzętu, oprogramowania systemowego, niezbędnego oprogramowania narzędziowego, sprawdzenie poprawności działania sprzętu itp. (alokacja elementów oprogramowania do składników sprzętowych). Następnie sprawdzony przez analityków i projektantów, poprawiony w razie konieczności usunięcia błędów programowych czy logicznych system zostaje zainstalowany na nowym sprzęcie i przetestowany na okoliczność poprawnego działania (dostosowania do działania) na tego typu sprzęcie.

17 NASTĘPNE FAZY ROZWOJU SYSTEMU
Wdrożenie systemu W opracowaniu tym traktowane będzie jako ponowne testowanie poprawności działania systemu w środowisku użytkownika końcowego i wyczyszczenie błędów oraz opracowanie ostatecznej dokumentacji systemu i szkolenie personelu w obsłudze systemu. W procedurze tworzenia systemu od samego początku, nie przewiduje się na tym etapie większych zmian organizacyjnych. Wszystkie, za wyjątkiem takich, które wynikają z ewentualnych błędów wykrytych podczas testowania, powinny zostać wychwycone i wprowadzone do systemu we wcześniejszych etapach budowy. Użytkowanie systemu Zasadniczo oparte jest na sprawdzeniu, ocenie poprawności działania i potencjalnych modyfikacjach parametrów systemu, wynikających już tylko z dodatkowych wymogów użytkowników końcowych systemu. Na tym etapie mogą być jedynie jeszcze wychwycone ewentualne błędy merytoryczne systemu. Należy też pamiętać że, codzienna eksploatacja systemu wymaga starannej konserwacji jego działania. Wycofanie systemu Następuje, gdy ze względów zużycia moralnego, rzadziej fizycznego systemu nie da się już eksploatować. Nastąpić to może w momencie gdy np. koszty ponoszone na konserwację i ciągłe modyfikacje systemu zaczynają stanowić znaczącą pozycje w budżecie firmy, gdy system zaczyna stanowić barierę ograniczającą wzrost firmy, gdy procedury integracyjne „starych” podsystemów spowalniają pracę firmy lub nie są możliwe do wykonania, gdy wszystkie firmy konkurencyjne w branży wymieniły już swój system na nowy lub szeregu innych okolicznościach. Wymiana oprogramowania związana jest bardzo często ze zmianą platformy działania systemu, zmianą systemu zarządzania bazą danych, pełna wymiana sprzętu itp. okolicznościami.

18 CYKL ŻYCIA SYSTEMU INFORMATYCZNEGO
Proces ciągły, wzorowany na cyklu życia organizmu, złożony z sekwencji wzajemnie spójnych, powiązanych ze sobą logicznie i logistycznie etapów umożliwiających stworzenie, wdrożenie i użytkowanie systemów informatycznych wspomagających zarządzanie Obejmuje okres od powstania u użytkownika potrzeby wprowadzenia systemu (narodziny) do wycofania systemu z eksploatacji (śmierć systemu)

19 ETAPY CYKLU ŻYCIA SYSTEMU INFORMATYCZNEGO
Wstępne rozpoznanie systemu Analiza informacyjna systemu Projektowanie systemu Oprogramowanie systemu Testowanie Instalacja Wdrożenie Eksploatacja Wycofanie systemu

20 MODEL CYKLU ŻYCIA MODEL CYKLU ŻYCIA - odwzorowanie procesu realnego postępowania w budowaniu systemu informatycznego uwzględniające poszczególne fazy cyklu życia w postaci kanonicznej (wcześniej przedstawionej) lub zmienionej przez istotne okoliczności zaburzające ten wzorzec, powodowane koniecznością: ścisłego dostosowania się do potrzeb informacyjnych konkretnej organizacji, wynikających z rozeznania tej organizacji lub: dostosowania się do wypracowanego przez firmę informatyczną i informatyzowaną organizacje konsensusu bądź: narzucenia organizacji potrzeb wynikających z własnego rozeznania systemu informacyjnego.

21 Tradycyjne modele cyklu życia systemu informatycznego

22 TRADYCYJNE MODELE CYKLU ŻYCIA SYSTEMU
Kaskadowy (liniowy) Ewolucyjny (równoległy) Przyrostowy Tworzenia baz danych (Fry’ego) Prototypowy Spiralny (Boehma) Trzy pierwsze modele stanowią jedynie de facto modyfikacje modelu liniowego, jednakże w literaturze bardzo często występują oddzielnie i stąd tutaj też przedstawione są jako niezależne propozycje

23 MODEL KASKADOWY Na początku każdego projektu istnieje stabilny zestaw potrzeb informacyjnych użytkownika i celów do których on dąży Potrzeby nie zmieniają się w trakcie życia systemu Proces budowy systemu odbywa się stopniowo, po skończeniu jednej fazy zaczynana jest następna Każdy kolejny etap oznacza uszczegółowienie i przybliżenie do rzeczywistości Powoduje to powrót do poprzednich etapów w momencie gdy zostanie wykryty błąd

24 MODEL KASKADOWY (LINIOWY)
Rozpoznanie Analiza Projekt Oprogramowanie Testy Instalacja Wdrożenie CZAS Eksploatacja P O S T Ę Y R A C

25 MODEL EWOLUCYJNY Cały system jest dzielony na moduły
Każdy z nich odbywa przejście przez kolejne fazy cyklu budowy systemu Na końcu działań projektowych przystępuje się do specjalnego etapu polegającego na integracji całego systemu i przeprowadzeniu testów W systemie podzielonym na części, których realizacja jest przesunięta w czasie łatwiej nadążać za zmieniającym się celem działania Ponieważ każdy moduł stanowi początkowo organicznie odrębną część należy zwrócić uwagę na niebezpieczeństwo związane z koniecznością integracji modułów w całość. Bardzo często staje się to główną przyczyną niepowodzeń realizacji projektu

26 MODEL EWOLUCYJNY E k s p l o a t c j P O S T Ę Y p R A C W d r o ż e n
i I n s t a l c j Oprogramowanie2 T e s t o w a n i Projekt2 Analiza2 Rozpoznanie2 Oprogramowanie1 Projekt1 Analiza CZAS Rozpoznanie1

27 MODEL PRZYROSTOWY Przeprowadzane jest rozpoznanie i analiza dla całości systemu. Powstaje całościowa koncepcja wstępna systemu poparta analizą całego systemu System podzielony na moduły realizacyjne projektowany, programowany i testowany jest kolejno dla każdego z nich. Małe zespoły robocze wykonują projekty techniczne dla każdego modułu i je testują Spójność systemu zapewniają założenia systemu oraz wspólne końcowe etapy instalacji i wdrożenia, w których przeprowadzana jest też integracja systemu. Jest to etap niesłychanie istotny ponieważ zapewnia pełną integrację systemu

28 MODEL PRZYROSTOWY E k s p l o a t c j Testowanie2 I n s t a l c j W d
Ę Y p R A C Testowanie2 I n s t a l c j W d r o ż e n i Oprogramowanie2 Projekt2 R o z p n a i e A n a l i z Testowanie1 Oprogramowanie1 Projekt1 Analiza1 CZAS

29 MODEL TWORZENIA STRUKTURY BAZ DANYCH
Rozpoznanie i analiza - zebranie potrzeb informacyjnych użytkowników Projekt techniczny: logiczny - opis modelu danych i przyszłych procesów w systemie fizyczny - projekt struktury zbiorów, wzorców dokumentów, technologii przetwarzania, specyfikacji wewnętrznych 3. Oprogramowanie i testowanie - stworzenie bazy danych i oprogramowanie zastosowań, testowanie oprogramowania 4. Instalacja - zainstalowanie oprogramowania w określonej platformie i konfiguracji sprzętowej 5. Eksploatacja i kontrola - użytkowanie, zapewnienie poprawności z ustalonymi normatywami i wymogami użytkownika 6. Modyfikacja i adaptacja - udoskonalenie funkcjonowania w wyniku pojawienia się nowych potrzeb - w razie potrzeby powrót do etapów początkowych

30 MODEL TWORZENIA STRUKTURY BAZY DANYCH
Rozpoznanie potrzeb i analiza Faza projektowania Projekt - logiczny - fizyczny Adaptacje i modyfikacje Programowanie i testowanie Faza eksploatacji Instalacja i wdrożenie Eksploatacja

31 MODEL PROTOTYPOWANIA Istota - zamiast budowy modelu "papierowego" oprogramowuje się schemat działania systemu Cel: redukcja czasu oczekiwania na rezultaty programowe szybkie sprzężenie użytkownika z projektantem ograniczenie liczby błędów większe zaangażowanie użytkownika w analizę i projekt Wymaga środków programowych typu CASE (Computer Aided System Engineering)

32 MODEL Z TWORZENIEM PROTOTYPU
Projekt techniczny i generacja oprogramowania Rozpoznanie i analiza Konstruowanie prototypu Użycie i weryfikacja prototypu Modyfikacja prototypu Testowanie i instalacja systemu Przekształcenie w ostatecznie funkcjonujący system Eksploatacja i modyfikacja systemu

33 MODEL SPIRALNY Budowę modelu rozpoczyna się od ustalenia wstępnych wymagań i analizy ryzyka ich realizacji Na tej podstawie buduje się pierwszy prototyp i tworzy konceptualny plan całości Po kolejnej fazie analizy ryzyka oraz zbadania ewentualnych alternatyw budowany jest następny prototyp i tworzy się wymagania dotyczące oprogramowania Powstaje plan tworzenia i odbywa się kolejny etap zakończony projektem oprogramowania Kolejny obieg przynosi projekt szczegółowy, oprogramowanie, testy i wdrożenie

34 MODEL SPIRALNY Ewaluacja alternatyw, identyfikowanie i likwidacja zagrożeń Określenie ograniczeń, celów i alternatyw Harmonogramowanie Analiza ryzyka Analiza ryzyka Wariantowanie Wstępne wymagania Analiza ryzyka czas Prototyp 1 Prototyp 2 ... ... Plan całości Zarys działania Projekt Plan tworzenia Wymagania szczegółowy oprogramowania Plan Projekt integracji i Oprogramowanie oprogramowania testowania i weryfikacja Testy Planowanie następnych faz Wdrożenie Konstruowanie

35 TRADYCYJNE METODY PROJEKTOWANIA

36 TYPOLOGIA METOD ANALIZY I PROJEKTOWANIA
metody strukturalne (T. DeMarco, V. Weinberg, E. Yourdon) metody obiektowe (P. Coad, E. Yourdon, J. Martin, J. Odell) metody operacyjne (M. Jackson) metody społeczne (P. Checkland)

37 Metody strukturalne Przedstawiają podejście formalne oparte na tworzeniu systemu całościowego, składającego się z wydzielonych elementów podrzędnych, o hierarchicznej strukturze zstępującej, powiązanych dobrze zdefiniowanymi modułami relacji i funkcji

38 Analiza w podejściu strukturalnym
Definiowanie modelu logicznego systemu - formalizacja wymagań użytkownika; szczegółowa specyfikacja zadań i funkcji realizowanych przez system, wyrażana za pomocą graficznych języków opisu: diagramy przepływu danych (DataFlow Diagrams), specyfikacje procesów (Process Specifications), diagramy relacyjne danych (Entity Relationship Diagrams), słownik danych (Data Dictionary), diagramy przepływu sterowania (SteeringFlow Diagrams), diagramy HIPO (Hierarchy Input-Process-Output), diagramy przejść stanowych (State Transition Diagrams)

39 Projektowanie w podejściu strukturalnym
Powstanie fizycznego modelu systemu model procesora model zadania model implementacyjny programu

40 Metody obiektowe Podejście bazujące na wyodrębnieniu obiektu (atrybuty; metody) Metody pozwalające na jednoczesne modelowanie danych i procesów Prezentują podejście bazujące na wyodrębnieniu abstrakcyjnego obiektu, charakteryzowane nie tylko parametrami atrybutów, ale i procesami, w którym on uczestniczy oraz funkcjami, przez nie wykonywanymi. Sprawia to, że obiekty nabierają dodatkowego wymiaru, pozwalającego na efektywniejsze modelowanie skomplikowanych procesów gospodarczych.

41 Grupy metod obiektowych
metody oparte na analizie struktur danych (np. G. Booch, D. Coleman) metody oparte na analizie zdarzeń (np. J. Martin, J. Odell) metody oparte na analizie scenariuszy zdarzeń (R. Wirfs-Brock, B. Wilkerson, L. Wiener)

42 Etapy w metodach obiektowych
specyfikacji systemu i analizy – tworzenie modelu obiektów oraz wariantów ich użycia (statyczna struktura systemu np. diagramy obiektów (Object Diagrams) oraz modelu interfejsów (dynamiczna struktura systemu: scenariuszy (Scenario Diagrams), modelu operacji użytkownika (Operation Model), słownika danych (Data Dictionary), modelu powiązań systemu obiektów (System Interface Graphs) projektu – realizacja poszczególnych operacji wyróżnionych na etapie analizy. Definiowanie procesu współdziałania obiektów np. w postaci opisu: grafów interakcji i widoczności obiektów, grafów, dziedziczenia, opisu klas, procesów, modułów implementacji – przekształcanie modeli fazy projektu na oprogramowanie. Składa się z diagramów stanów i ich zmian oraz generacji bądź tworzenia kodu

43 Metody operacyjne Podejście, w którym przedstawia się transformację danych wejściowych na dane wyjściowe (modelowanie struktur systemu oprogramowania na podstawie struktur danych), rozpoczynające się od wyodrębnienia obiektów i funkcji przez nie wykonywanych, łączących się w procesy, dekomponowane następnie na poziom fizyczny

44 Etapy w metodach operacyjnych
Analiza – tworzenie modelu struktur danych, do transmisji danych wejściowych do stanu wyjściowego. Podstawowym narzędziem: diagramy struktur danych (Data Structure Charts) – pozwalające na modelowanie hierarchiczne drzew danych, Specyfikacja – budowa schematu przepływów struktur danych przez programy, zapewniające powiązania pomiędzy danymi. Podstawowe narzędzie: sieci specyfikacji systemu (System Specification Network). Implementacja – definiowanie modelu struktury programów odzwierciedlających zaprojektowane wcześniej struktury danych. Narzędziem są tutaj diagramy struktury programów (Program Structure Charts), wykorzystujące dokładnie te same drzewiaste notacje, jakie występowały podczas modelowania struktur danych

45 Metody społeczne Oparte są na teorii rozwiązywania konfliktów - socjologiczno-psychologicznych negocjacjach zmian z grupami pracowniczymi oraz grupami kreującymi system. Z wynegocjowanych zmian wynika docelowa, pożądana postać systemu, jego celów i funkcji, która następnie jest informatyzowana.

46 Metody społeczne Akcentują w procesie analizy i projektowania systemu informatycznego uwzględnienie zagadnień satysfakcji użytkownika i twórcy systemu z wykonywanej pracy, partycypacji wszystkich osób i jednostek organizacyjnych w tworzeniu systemu, szerokiego współuczestnictwa wszystkich stron i interesów w procedurze projektowej (W. Mumford, P. Checkland)

47 Fazy w metodach społecznych
Analiza i założenia systemu – definicja sytuacji problemowych oraz odwzorowań struktury i dynamiki między stanowiskami i komórkami organizacyjnymi, powiązań formalnych i zależności nieformalnych, charakterystyka struktury i dynamiki sytuacji problemowej z opisem uczestników i ich ról w procesie budowy systemu, stworzenie systemu modeli konceptualnych (sekwencji wzajemnie powiązanych procesów realizowanych w celowej działalności) Weryfikacja – odniesienie systemu modeli konceptualnych do rzeczywistości, określenie i przeprowadzenie pożądanych zmian Formalizacja i implementacja – technicystyczne odwzorowanie na model fizyczny ze wskazaniem na interakcyjne techniki prototypowania, pakiety wspomagane analizą ryzyka, systemy probabilistyczne, analizy wielokryterialne, systemy sztucznej inteligencji

48 Cechy charakterystyczne metod tradycyjnych
przewidywalne i powtarzalne podeście do procesu rozwoju projektu – w klasycznych metodykach zakłada się zwiększającą się szczegółowość w miarę realizacji poszczególnych faz i etapów rozwoju projektu i obejmowanie całego okresu od początku do końca projektu. Do analiz przeprowadzanych na bardzo niskim stopniu abstrakcji stosuje się na ogół deterministyczne techniki szczegółowe. Wynik uzyskany przy ich pomocy jest prawdziwy, dopóki przynajmniej jedno z założeń początkowych nie zostanie zmienione. Zakłada się więc deterministyczny, niezmieniany, nieadaptowany i mało elastyczny harmonogram, budżet i zasoby – na tej podstawie jest budowany pełen podział zadań dla każdego zespołu tworzącego produkt lub usługę,

49 Cechy charakterystyczne metod tradycyjnych
obszerna dokumentacja – tradycyjne podeście do realizacji projektu zakłada, że dokumentacja jest tworzona po każdej fazie, a często i etapie cyklu życia projektu. W najbardziej konwencjonalnej formie modelu kaskadowego przyjmuje się, że zakres oraz wymagania dotyczące użytkownika są zbierane i ustalana w pierwszej fazie cyklu (patrz powyżej), a następnie na ich podstawie tworzony jest produkt lub realizowana usługa. Nie zmienia się tych założeń do końca cyklu życia projektu, część zebranych i przekształconych w zalecenia wykonawcze informacji i dokumentów wymaga przez to zmian w trakcie realizacji projektu,

50 Cechy charakterystyczne metod tradycyjnych
zorientowanie na proces – celem klasycznych metodyk jest w zasadzie określenie procesu/ów, które będą uniwersalne i powtarzalne, czyli będą funkcjonowały w prawidłowy sposób (no i będą przydatne dla każdego, kto je będzie używał), w każdej sytuacji w której wydadzą się przydatne. Każdy proces, składający się z zadań/czynności powinien być wykonywany według określonych z góry procedur przez określoną, przypisaną do niego i odpowiedzialną za niego grupę pracowników lub wykonawcę, zorientowanie na narzędzia i techniki wspomagające realizację – do wykonania każdego określonego w projekcie zadania powinny być dostarczone odpowiednie narzędzia wspomagające zarządzania.

51 Nowoczesne metody projektowania systemów informatycznych

52 Dwanaście zasad tworzenia zwinnego (agile) oprogramowania
Najważniejsze dla nas jest zadowolenie Klienta wynikające z wcześnie rozpoczętego i ciągłego dostarczania wartościowego oprogramowania. Bądź otwarty na zmieniające się wymagania nawet na zaawansowanym etapie projektu. Zwinne procesy wykorzystują zmiany dla uzyskania przewagi konkurencyjnej Klienta. Często dostarczaj działające oprogramowanie od kilku tygodni do paru miesięcy, im krócej tym lepiej z preferencją krótszych terminów. Współpraca między ludźmi biznesu i programistami musi odbywać się codziennie w trakcie trwania projektu. Twórz projekty wokół zmotywowanych osób. Daj im środowisko i wsparcie, którego potrzebują i ufaj im, że wykonają swoją pracę. Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji do i ramach zespołu jest rozmowa twarzą w twarz Podstawową i najważniejszą miarą postępu jest działające oprogramowanie. Zwinne procesy tworzą środowisko do równomiernego rozwijania oprogramowania. Równomierne tempo powinno być nieustannie utrzymywane poprzez sponsorów, programistów oraz użytkowników. Poprzez ciągłe skupienie na technicznej doskonałości i dobremu zaprojektowaniu oprogramowania zwiększa zwinność. Prostota – sztuka maksymalizacji pracy niewykonanej – jest zasadnicza. Najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach. W regularnych odstępach czasu zespół zastanawia się jak poprawić swoją efektywność, dostosowuje lub zmienia swoje zachowanie.

53 Założenia metodyk nowoczesnych (zwinnych)
zorientowanie na interesariuszy projektu – jest to wg tych metodyk najważniejszy czynnik związany z rozwojem projektu, a jednocześnie zadanie dla kierowników zespołów „zwinnych” projektów - kładzenie większego nacisku na ludzi wraz z ich umiejętnościami takimi jak: ambicje, zdolności oraz wzajemna komunikację. Jeżeli zespół nie jest zaangażowany w projekt, to żaden proces nie naprawi ich nieadekwatności, adaptacyjność – w tym podejściu kładzie się nacisk na zarządzanie zmianą. Sprzyja to przekazaniu użytkownikowi własnej wiedzy większej niż minimalna zakładana projektem. Zarządzanie zmianą zakłada ciągłą reakcję na ciągle zmiany zachodzące projekcie. Najtrudniejsze do oceny i reakcji są zewnętrzne zmiany środowiskowe – ponieważ nie jest możliwa ich eliminacja – należy dążyć do minimalizacji kosztów z nimi związanych,

54 Założenia metodyk nowoczesnych (zwinnych)
zgodność z rzeczywistością – zwraca się uwagę na zgodność otrzymanych rezultatów z uzyskanymi wynikami projektu, niż zgodność z wynikami początkowo zakładanymi, elastyczność planowania – podstawowym problemem planowania projektu jest brak możliwości przewidzenia implikacji rozwoju planów przedsięwzięć innowacyjnych, ponieważ środowisko, w którym powstają jest wysoce dynamiczne. W „zwinnych” projektach, wykonawcy muszą zastanowić się, jak mogą uniknąć nieodwracalności swoich decyzji - wymuszonych przyzwyczajeniem do praktyki szczegółowego projektowania tradycyjnego, które prowadzi do daleko posuniętej szczegółowości. Zamiast próbować podjąć właściwe decyzje na początku każdego cyklu (projektowanie tradycyjne), lepiej ją podjąć w taki sposób, żeby w następnych etapach można było je odwrócić,

55 Założenia metodyk nowoczesnych (zwinnych)
oparcie się na procesach empirycznych – w metodach tradycyjnych procesy występują jako deterministyczne i liniowe w metodach „zwinnych” jako proces empiryczny (probabilistyczny, źle lub słabo ustrukturalizowany), bądź nieliniowy. Proces deterministyczny, taki w którym od rozpoczęcia, do zakończenia, można za każdym razem spodziewać się takich samych wyników. Projektów poprzez cechę wyjątkowości, jednorazowości itp. nie można zdefiniować jako procesów deterministycznych, ponieważ w czasie ich realizacji może się rozwijać i produkt i zespół projektowy. Jest bardzo mało prawdopodobne, aby jakikolwiek zestaw predefiniowanych kroków doprowadzić do pożądanego, przewidywalnego wyniku, ponieważ zmieniają się wymagania technologiczne oraz ludzie wewnątrz zespołu projektowego,

56 Założenia metodyk nowoczesnych (zwinnych)
wykorzystanie podejścia zdecentralizowanego – zdecentralizowany styl zarządzania może znacząco wpłynąć na projekt, ponieważ może on zaoszczędzić więcej czasu niż podeście autokratyczne. W metodykach lekkich deleguje się część zadań związanych z podejmowaniem decyzji do wszystkich członków zespołu (w rzeczywistości nie zawsze jest to jednak możliwe), prostota – w projektowaniu prowadzonym metodykami lekkimi zawsze wybierana jest najprostszą drogę prowadząca do celu - zakłada się łatwe zmiany modelowe, które dostosowywane są do bieżących potrzeb i mogą następować w różnych terminach. Nie wytwarza się większej funkcjonalności, niż ta, która jest w danym momencie konieczna, ani dokumentacji próbującej przewidzieć przyszłość projektu. To zmniejsza koncentrację na znalezienie informacji potrzebnych do tych predykcji

57 Założenia metodyk nowoczesnych (zwinnych)
komunikacja - oparcie się współpracy z odbiorcą (użytkownikiem finalnym) i współpracy wewnętrznej – klient projektu powinien ściśle współpracować z zespołem projektowym, zapewniając mu wszelkie potrzebne informacje oraz zgłaszać bieżące uwagi i komentarze do projektu. Ze względu na decentralizację zespół wykonawczy w metodykach „zwinnych” powinien się w sposób ciągły komunikować ze sobą. funkcjonowanie w małych, samoorganizujących się zespołach – gdzie obowiązki i zadania przekazywane są do zespołu jako całości, a zespół rozdzielając je, zapewnia najlepszy sposób ich realizacji. W małych zespołach najlepiej sprawdza się idea ciągłej komunikacji. Struktura procesu i konkretne praktyki tworzą minimalne, elastyczne ramy strukturalne dla zespołów samoorganizujących.  Odpowiednie ich wykorzystanie znacznie zmniejsza ryzyko związane z czynnikiem ludzkim.

58 Nowoczesne (zwinne, lekkie) metody projektowania
XP - eXtreme Programming, Scrum, Feature Driven Development (FDD) – metodyka programowania rozwoju ukierunkowanego na wyróżnione cechy projektu (własności), Dynamic System Development Method (DSDM) – metodyka dynamicznego rozwoju systemu i Adaptive Software Development (ASD) - adaptacyjny rozwój oprogramowania.

59 Założenia i zalecenia metodyki XP
specyfikacje projektowe są prawie zawsze niepełne, wieloznaczne, a nawet czasem sprzeczne wewnętrznie. Co prawda zakłada się, że przy dobrym i stałym kontakcie ze świadomym klientem może się nawet obyć bez specyfikacji, ale dotyczy to tylko małych projektów, planowanie zwrotne – wykonawcy szacują czas niezbędny do realizacji zadań zgłoszonych przez klienta, klient je koryguje, po czym następują negocjacje, co do czasów i zadań, które można w tych okresach wykonać, iteracyjność – każda aplikacja tworzona jest w kolejno po sobie następujących iteracjach, każda z nich przybliża planowaną wersję do ostatecznych wymagań. System tworzy się w kolejnych iteracjach, planują tylko następną. Po jej skończeniu i powstaniu wersji spełniającej przyjęte dla iteracji założenia planuje się dopiero następną iterację itd.,

60 Założenia i zalecenia metodyki XP
jednolity język komunikacji – dopracowanie się języka (zbiór, dziennik), w którym poszczególne kategorie mają to samo znaczenie dla wykonawcy i klienta, prostota architektury – uzyskiwany produkt powinien być jak najprostszy, a skomplikowane propozycje zastępowane mniej złożonymi. Z drugiej strony architektura jest labilna – jeśli jej zmiana ma przyspieszyć, bądź ułatwić realizację bieżącej iteracji i nie pogarsza wyników testowania, uzyskanych w uprzednich, to należy ja wprowadzić, refaktoryzacja – restrukturyzacji systemu poprzez usunięcie elementów dublujących się, poprawieniu komunikacji czy uproszczeniu modelu, bez zmiany założonej funkcjonalności programu. Wszelkie poprawki wykonywane są przed wprowadzeniem nowej funkcjonalności,

61 Założenia i zalecenia metodyki XP
praca dwójkami – naprzemienne wykonywanie przydzielonego wspólnego zadania, w celu poprawienia zastępowalności, wzajemnego uczenia się i kontroli poprawności, co zwiększa jakość wykonywanego zadania. Obydwie osoby mają szansę dokładnie poznać kod źródłowy programu i po sobie poprawiać błędy (co eliminuje skutki informatycznego powiedzenia …obyś cudze programy poprawiał…). Może zmniejszyć wydajność pracy, przynajmniej początkowo. W praktyce często podział pracy w dwójkach jest inny niż zakładali autorzy metody (jedna osoba przygotowuje analizy i bieżące projekty; druga programuje), wspólna odpowiedzialność projektowa – każdy z członków zespołu może zmienić w dowolnym momencie poszczególne efekty dotychczasowych wyników projektu. Z drugiej strony jest to poważna niedogodnością – brak jest jednej osoby odpowiedzialnej i każdy może „grzebać” w kodzie,

62 Założenia i zalecenia metodyki XP
natychmiastowe i ciągłe integrowanie (continuous integration) nowych fragmentów pracy z powstającą całością oraz testowanie już zintegrowanych rozwiązań, samodyscyplina wyrażająca się przeznaczaniem określonego czasu na prace projektowe dla każdego członka zespołu zadaniowego oraz przestrzeganiem ustalonych na początku standardów wykonywania pracy – komunikacyjnych, formalnych i merytorycznych (w praktyce jest to często realizowane równie dowolnie jak w metodzie ewolucyjnej), utrzymywanie stałego kontaktu z klientem – tworzone na podstawie analizy specyfikacje wymagań klienta są często wieloznaczne i niekompletne. Należy zatem w ciągły sposób je korygować poprzez utrzymywanie kontaktów z klientami, którzy na bieżąco weryfikują uzyskane rezultaty.

63 Cykl życia w XP analiza i założenia wstępne – analiza opłacalności w świetle wyspecyfikowanych wymogów użytkownika i jego ograniczeń, budowa ogólnego modelu biznesowego i zadań stojących przed wykonawcą, wybór środowiska i narzędzi implementacji, negocjacje kontraktowe. Etap wspólny dla całości projektu, nie zawsze uwzględniany w tej metodyce, planowanie i modelowanie wersji - przedstawienie dopuszczalnego wariantu/ów rozwoju projektu dla każdej funkcjonalności, w którym wykorzystywane są ustalenia poprzedniego etapu, rozpisanie projektu na zadania przedstawione przez klientów i przypisanie im priorytetów i umieszczenie w harmonogramie realizacyjnym,

64 Cykl życia w XP kolejne iteracje - powstanie prototypu na podstawie poprzedniego etapu, przedstawienie go klientowi, wprowadzenie zmian, wykonanie kolejnego prototypu itd. w ich wyniku – powstanie architektury i implementacji wybranych funkcji kolejnych wersji, testy funkcjonalności – kolejne wersje przedstawiane klientowi są testowane przed następnymi modyfikacjami, które może na tym etapie sugerować, po wypracowanie ostatecznej postaci wersji każdej funkcjonalności następuje jej integracja z pozostałymi, dostarczenie ostatecznej wersji projektu i jej wykonanie – ostatnia iteracja doprowadza do stworzenia ostatecznej, kompletnej wersji projektu, która jest następnie realizowana.

65 Podstawowe fazy cyklu życia projektu w modelu XP
Analiza i założenia wstępne całości projektu Weryfikacja w kolejnych iteracjach Wersja ostateczna i jej wykonanie Planowanie i modelowanie wersji kolejnych funkcjonalności Powstanie prototypu (I wersja) dla kolejnej funkcjonalno-ści Powstanie kolejnego n-tego prototypu Testy funkcjonalności i integracja Czy odpowiada wymaganiom?

66 SCRUM – praktyki projektowania
tworzenie rejestru zamówień (Product Backlog) – czyli lista wszystkich wymagań użytkownika: funkcji i ustalonych z realizatorem zmian wraz z priorytetami, czekająca na realizację (odpowiedzialny użytkownik końcowy - właściciel produktu (Product Owner)), cykl pracy - przebieg (Sprint) – etap pracy zespołu projektowego (od jednego do sześciu tygodni, z zaleceniem regularności i jednolitości długości trwania każdej iteracji np. miesiąc). W każdym cyklu jest dostarczana użytkownikowi do przetestowania i oceny następna działająca wersja prototypu produktu, planowanie cyklu pracy - przebiegu (Sprint Planning Meeting) – składa się z dwóch części: analizy i projektu realizacji. W pierwszej wraz ze wszystkimi użytkownikami zespół projektowy ustala kompletny (w danym momencie) zbiór celów i funkcji systemu. W drugiej – kierownik projektu (Scrum Master) z zespołem uzgadnia najlepszy sposób realizacji produktu podczas danego przebiegu,

67 SCRUM – praktyki projektowania
tworzenie rejestr zamówień dotyczącego konkretnego przebiegu (Sprint Backlog) – lista nowych lub zmienionych funkcjonalności przypisana do kolejnego przebiegu. W momencie jej realizacji powstaje nowa wersja prototypu, weryfikacja postępu prac (Daily Scrum Meeting) – odbywa się w trakcie obowiązkowych codziennych spotkania zespołu projektowego. Polega na identyfikacji niezbędnych zmian i określenia warunków ich realizacji przez zespół (na zasadach samorealizacji).

68 Cykl życia w metodzie Scrum
rozpoznanie ogólnych wymagań i wstępna analiza informacyjna całości systemu, rozpoznanie i analiza dla kolejnego, bieżącego przebiegu, planowanie przebiegu (analiza i projekt techniczny, bieżąca weryfikacja założeń w trakcie codziennych spotkań, realizacja systemu i generacja oprogramowania kolejnego prototypu – konstruowanie i zastosowanie, testowanie systemu po kolejnym przebiegu, eksploatacja i potencjalne , przyszłe modyfikacje systemu.

69 Cykl życia systemu informatycznego w metodyce Scrum

70 Cykl życia systemu informatycznego w metodyce Scrum
Przed każdym przebiegiem odbywa się spotkanie zespołu realizacyjnego z użytkownikami identyfikujące priorytetowe zadania (określenie zakresu, zawartości i intencji użytkownika) oraz konwertujące je w funkcjonalności przyszłego systemu. Na tej podstawie tworzony jest plan wykonania oprogramowania w bieżącej iteracji (priorytety, podział obowiązków, szczegółowe działania). Natomiast na początku każdego dnia przebiegu (w niektórych interpretacjach tej metodyki na zakończenie dnia) odbywa się – w trakcie spotkania zamkniętych zespołu projektowego - bieżąca weryfikacja realizacji zadań (stan wykonania, problemy ogólne i szczegółowe realizacji oraz jednostkowe sposoby ich rozwiązania). Ma na celu koordynacje i synchronizację dziennej pracy członków zespołu. Po każdej iteracji odbywa się natomiast spotkanie z użytkownikiem w celu prezentacji produktu kolejnej iteracji i określenia czy realizuje on kierunek zmian przez niego oczekiwany. Ma ono pomóc klientowi w określeniu czy i co w następnej kolejności powinno być wykonywane. Na podstawie wniosków z tego spotkania produkt zostaje przekazany do testowania i użytkowania lub w kolejnej iteracji do dalszych modyfikacji.

71 Założenia metodyki Feature Driven Development (FDD)
głównym elementem jest cecha (feature) produktu – wydzielony zakres funkcjonalności projektu istotny z punktu widzenia klienta, lista cech jest budowana po stworzeniu ogólnego model biznesowego (obiektowy model nieformalny zawierający cele i ideę produktu oraz jego założenia i alternatywne rozwiązania). Jej zawartość musi pokrywać się z wymaganiami dostarczonymi przez klienta (użytkownika), na tej podstawie konstruowany jest plan implementacji cech określający w jakiej kolejności będą realizowane cechy produktu oraz harmonogram jego realizacji wraz z przypisaniem poszczególnych zadań członkom zespołu projektowego,

72 Założenia metodyki Feature Driven Development (FDD)
zastosowanie procedury „interpretacyjnej” polegającej na dostarczaniu kolejnych, działających wersji produktu w iteracjach polegających na przeplataniu się faz projektowania szczegółowego wybranych cech produktu oraz ich implementacji, aż do uzyskania konsensusu z użytkownikiem końcowym. realizacja tej procedury odbywa się poprzez przydzielenie cech zakwalifikowanych do wykonania w danej iteracji dynamicznie tworzonym małym (2-3 osoby) zespołom projektantów i programistów. Każdemu z nich przypisywana jest klasa biznesowa związana z funkcjonalnością danej cechy. Pozostali członkowie zespołu testują napisany fragment oprogramowania i integrują z resztą produktu.

73 Fazy cyklu życia FDD budowa koncepcji nieformalnego modelu ogólnego – skonstruowanie opisowego na ogół modelu ogólnej architektury systemu – swoiste założenia budowy systemu, analiza systemu – polega na skonstruowaniu specyfikacji użytkowych dla wyróżnionych, niewielkich, użytecznych cech systemu, typu elementarnego, które są następnie grupowane w obszary funkcjonalne, a w razie potrzeby i dziedzinowe, projekt systemu - zgodnie z powyższym tworzony jest, w uzgodnieniu z klientem, plan konstrukcji oprogramowania według wyselekcjonowanych cech realizowanych zgodnie z priorytetami użytkownika końcowego. Często na tym etapie dodatkowo szacuje się pracochłonności wykonania poszczególnych modułów oprogramowania oraz ryzyko związane z ich wykonaniem. Prace nad projektem odbywają się w tworzonym na czas każdej iteracji zespole, złożonym z przedstawicieli (właścicieli) klas rozpatrywanej właśnie grupy cech. Zespół ten modyfikuje, bądź uszczegóławia bieżący projekt i dopuszcza do implementacji,

74 Fazy cyklu życia FDD implementacja systemu – kolejna wersja systemu dla kolejnego zestawu cech jest przedstawiana użytkownikowi. W następnej iteracji albo jest modyfikowana zgodnie z sugestiami użytkownika, albo akceptowana do realizacji. dwie ostatnie fazy powtarzają się iteracyjnie do końca projektu. Po każdej iteracji klientowi dostarczana jest kolejna wersja oprogramowania.

75 Fazy cyklu życia FDD

76 Dynamic System Development Method (DSDM)
na początku projektu jednokrotnie przeprowadzana jest inspekcja zastosowalności, zawierająca uzasadnienie dla zastosowania tej metody oraz identyfikację potencjalnych zagrożeń dla jej pomyślnej realizacji, następnie tworzony jest model biznesowy obejmujący: opis (charakterystyka konceptualna systemu) i specyfikację zakresu systemu, zarys architektury systemu i plan prototypowania,

77 Dynamic System Development Method (DSDM)
na podstawie modelu biznesowego buduje się szczegółowy iteracyjny model funkcjonalny, polegający na naprzemiennym procesie analizy i budowy kolejnych (coraz lepszych, uzgadnianych z użytkownikiem końcowym) prototypów. Wynikiem jest całościowy model funkcjonalny obudowany oprogramowanymi prototypami. W każdym przebiegi iteracyjnym tworzy się listę bieżąco opracowywanych funkcjonalności oraz dotyczących ich prototypów realizacyjnych; uwagi, komentarze, zalecenia – od użytkownika i/lub uzgodnienia z użytkownikiem; pozostałe wymagania niefunkcjonalne (organizacyjne, ekonomiczne, techniczne, psychologiczne, prawne itd.); analiza ryzyka opłacalności związanego z kontynuacja prac nad projektem,

78 Dynamic System Development Method (DSDM)
w kolejnych iteracjach powstają nowe, coraz bardziej zbliżone do wymogów użytkownika projekty, ostateczny model funkcjonalny zostaje oprogramowany, a przetestowane prototypy włączone w jego zakres (adaptowane). Powstaje produkt zawierający uzgodniony wcześniej i przetestowany zestaw funkcjonalności, gotowy produkt w momencie wdrażania jest obudowywany dokumentacją końcowa, instrukcjami i szkoleniami dla użytkowników.

79 Zalety DSDM Podstawową zaletą metodyki DSDM jest to, że na każdym etapie projektowania i budowy systemu produkt jest oceniany przez twórców i użytkowników, a uwagi wynikające z ich oceny opracowywane są w ramach kolejnych iteracji. Do innych zalet tej metodyki można zaliczyć również: wysoką jakość i adaptacyjność wobec zmieniających się wymagań , krótki czas dostarczenia poszczególnych wersji produktu. Oprócz początkowej analizy ryzyka wykonalności metodyka ta, jako żywo przypomina tradycyjne metody prototypowe.

80 Cykl życia DSDM

81 Metoda Adaptive Software Development - ASD
oparcie się na dynamicznych spekulacjach (rozważaniach o możliwościach wariantowania i potencjalnych zmian), współpracy z użytkownikiem i wyciąganiu wniosków z bieżącej sytuacji (nauce), identyfikacja i wyjaśnienie wszelkich założeń niezbędnych do realizacji projektu (spekulacje), ścisła współpraca oparta o natychmiastową, szybką i efektywną komunikacją pomiędzy członkami zespołu projektowego (i ewentualnie podzespołami), szybkie reagowanie na błędy i odchylenia od ustaleń projektu oraz ewentualne zmiany wymagań (nauka).

82 Metoda Adaptive Software Development - ASD
W odróżnieniu od podejścia tradycyjnego, w którym odchylenie od planu (spowodowane przyczynami obiektywnymi lub wymogami użytkownika) jest traktowane jako błąd do korekty, w podejściu adaptacyjnym, kreowanym przez ASD, takie odchylenia prowadzą do poprawnych rozwiązań ponieważ są przyjmowane za poprawne i z góry pożądane. ASD nie posiada tak szczegółowych zasad i procedur jak inne metody nowoczesne, lecz ale stanowi jedynie zespół wskazówek, pewne podejście do tego, jak należy zachęcać członków zespołu do współpracy i uczenia się w ramach projektu. Zamienia statyczny plan działania, na zmieniający się w czasie – dynamiczny, zależny od wyników poprzednich etapów (nadążny za zmieniającym się celem).

83 Metoda Adaptive Software Development – ASD – cykl życia
spekulacji (inicjalizacja (rozpoznanie); definicja celu; ustalenie czasu trwania projektu, określenie maksymalnej liczby realizowanych w iteracjach przybliżeń kolejnych prototypów i czasu ich trwania; wybór zakresy funkcjonalnego i celu działania każdego prototypu; prototypowanie, dyskusja rezultatów każdej iteracji, dalsze modyfikacje lub zatwierdzenie postaci ostatecznej, współpracy – przetestowanie i wdrożenie ostatecznej postaci systemu, stworzenie dokumentacji w ścisłej współpracy z użytkownikiem systemu, dzielenie się z nim wiedzą i wspólne podejmowanie decyzji wdrożeniowych. nauki – po każdej iteracji następuje etap oceny jakości prototypu z punktu widzenia użyteczności dla klienta, innowacyjności i jakości zastosowanych rozwiązań technicznych, efektywności funkcjonowania zespołu projektowego oraz bieżącego stopnia wykonania projektu (jego statusu).

84 Metoda Adaptive Software Development – ASD – cykl życia

85 Podobieństwa metod tradycyjnych i nowoczesnych
pomimo deklarowanych różnic podobieństwo faz cyklu życia projektu i całej procedury projektowej, pomimo deklarowanej (Manifesto for Agile…) innowacyjności i odrębności „czerpanie” całą garścią z dorobku poprzednich metodyk twardych, bądź socjo-psychologicznych, pomimo wymyślnego nazewnictwa podobieństwo charakteru procedur postepowania, pomimo deklaratywnej szczegółowości podobieństwo w opieraniu się na danych przybliżonych, co wielokrotnie prowadzi do rozminięcia się oczekiwań użytkownika z wykonawcą.

86 Pokrycie faz cyklu życia przez poszczególne metody
Etap cyklu życia/ Metody zwinne Inicjacja/koncepcja Analiza Projektowanie Oprogramowanie Testy Wdrożenie Adaptive Software Development X Dynamic System Development Method Extreme Programming Feature-Driven Development SCRUM

87 Czynniki decydujące o zastosowaniach nowych rozwiązań
rodzaj i harmonogram finansowania prac zawarty w umowie z klientem - jeżeli zakłada się wykładniczy sposób finansowania, to należy stosować metodyki zwinne. W tych metodykach przyjmuje się, że czynnikami ważniejszymi niż negocjowanie kontraktów są zaufanie i współpraca partnerów biznesowych (przynajmniej deklaratywnie). W trakcie podpisywania umowy i wstępnego ustalania harmonogramu albo przyjmuje się realizację budżetu od początku korzystną dla klienta (powoli rosnąca na początku projektu, wykładniczo wraz z przekazywaniem uzgodnionych, przyjmowanych przez użytkownika produktów albo na kontraktach o niewielkim stopniu ryzyka dla realizatora projektu (np. umowy z refundowanym kosztem wg cen stałych). Jeżeli natomiast zakłada się logarytmiczną funkcję realizacji budżetu, (wysoką w stadiach początkowych, stabilizującą się w późniejszych fazach projektu), to – zwłaszcza dla firm o ugruntowanej pozycji na rynku opłaca się przyjąć, jedną z metodyk klasycznych,

88 Czynniki decydujące o zastosowaniach nowych rozwiązań
typ budżetu - nierównomiernie rozłożony w czasie budżet projektu, wymuszający różną intensywność prac oraz wysoki stopień niepewności wskazuje na efektywniejsze użycie metodyki zwinnej. Zaś budżet finansujący projekt w sposób równomierny i stały w czasie sugeruje wykorzystanie metodyki klasycznej, charakter ustaleń harmonogramu - narzucone w harmonogramie sztywne założenia czasowe w stosunku do zaplanowanych zadań przemawiają na korzyść zastosowania metodyk klasycznych, przybliżone lub relatywne terminy realizacji – sugerują użycie metod zwinnych, ilość i poziom wymaganej dokumentacji oraz poziom jakości oprogramowania - spełnienie złożonych wymagań związanych z formalnymi standardami dokumentacji, licencjami czy certyfikacji wskazuje na konieczność zastosowania klasycznej metodyki zarządzania projektem. Natomiast projekt, w którym nacisk kładziony jest na jakość oprogramowania i możliwości jego rozwoju jest zgodny z filozofią metodyk zwinnych,

89 Czynniki decydujące o zastosowaniach nowych rozwiązań
podejście do ryzyka projektowego – niskie ryzyko projektowe obsługują lepiej metodyki zwinne. Wysokie ryzyko w projekcie wymusza stosowanie metodyk klasycznych, w których zakłada się tworzenie planów minimalizacji ryzyka lub sytuacji awaryjnych, komunikacja z klientem - metodyki zwinne zakładają ciągłą oraz bezpośrednią komunikację z klientem. Zmniejszane są więc wszelkie czynniki związane z niezrozumieniem realizowanych zadań. W metodykach klasycznych preferuje się rzadszy kontakt z klientem, co prowadzi bardzo często do nieporozumień w momencie prezentacji i przekazania zrealizowanego systemu,

90 struktura organizacyjna konieczna do realizacji projektu - przedsiębiorstwa o strukturze hierarchicznej lub pokrewnych, zawierające w swoich strukturach ścisłe wyspecjalizowane jednostki będą preferować metodyki klasyczne. Przedsiębiorstwa o strukturze np., macierzowej, projektowej lub innej, w której mogą sobie pozwolić na delegowanie zadań projektowych do mniejszych zespołów, w których nie ma ściśle zdefiniowanej hierarchii organizacyjnej powinny zdecydować się na wybór metodyki klasycznej, sektor/branża realizacji projektu – związana często ze strukturami organizacyjnymi też znacząco wpływa na realizację projektu. Branże, które na wejściu mają niewielką liczbę surowców i materiałów, a na wyjściu gotowych produktów - lepiej nadają się do użycia w trakcie projektowania systemu metod klasycznych,

91 Czynniki decydujące o zastosowaniach nowych rozwiązań
wielkość projektu – część środowisk programistycznych związanych z wdrożeniami wielkich systemów uważa, że metody klasyczne lepiej nadają się do realizacji tego typu projektów. W metodykach zwinnych, trudno przy wielkich projektach, nawet powtarzalnych, skoordynować działania wielu małych grup realizujących projekt, rodzaj systemu, dla którego projekt jest realizowany – systemu eksperckie lub oparte o bazę wiedzy wymagają bardzo często specjalistycznej wiedzy o realizowanym zagadnieniu. Jeśli są to systemy z założenia konstruowane jako samouczące zaleca się stosowanie metodyk nowoczesnych, w przeciwnym przypadku – dla systemów opartych o ustalone wzorce postępowania – metodyk klasycznych, czynniki psychologiczne – np. doświadczenie zespołu realizacyjnego w stosowaniu metodyk zwinnych lub klasycznych; zaufanie organizacji, w której projekt jest realizowany do zespołu projektowego; wysoki stopień wykorzystania w zespołach mieszanych specjalistów ze strony przyszłego użytkownika itp.

92 Porównanie sukcesu projektów realizowanych za pomocą metod tradycyjnych i nowoczesnych

93 Kierunki rozwoju metodyk projektowania systemów informatycznych

94 Witold Chmielarz - Wydział Zarządzania UW
DZIĘKUJĘ ZA UWAGĘ! Witold Chmielarz - Wydział Zarządzania UW