OpublikowałBarbara Smolińska Został zmieniony 2 lata temu\n1 ANALIZA, PROJEKTOWANIE I WDROŻENIE INFORMATYCZNYCH SYSTEMÓW ZARZĄDZANIA\n2 Zakres tematyczny 1. Wprowadzenie 1.1. System informacyjny i informatyczny organizacji 1.2. Typologia systemów informatycznych 2. Podejście badawcze do tworzenia systemów informatycznych 2.1. Podstawy teoretyczne budowy systemów informatycznych 2.2. Etapy rozwoju systemów informatycznych 2.3. Cykl życia systemu informatycznego 2.4. Klasyczne techniki gromadzenia informacji w analizie i projektowaniu systemów Techniki zbierania danych od użytkownika Techniki prezentacji systemów\n3 Zakres tematyczny 3. Tendencje w analizie i projektowaniu systemów informatycznych 3.1. Typologia metod projektowania 3.2. Charakterystyka metod strukturalnych analizy i projektowania systemów 3.3. Charakterystyka metod obiektowych analizy i projektowania systemów 3.4. Analiza porównawcza metod analizy i projektowania systemów 4. Narzędzia wspomagające analizę i projektowanie systemów informatycznych 4.1. Charakterystyka ogólna narzędzi wspomagających budowę systemów 4.2. Szczegółowa charakterystyka wybranych narzędzi wspomagających analizę i projektowanie systemów Prezentacja pakietu Oracle CASE Analiza możliwości zastosowań pakietu Baan Orgware 5. Metodyki oceny i selekcji systemów informatycznych – analiza przypadków\n4 PROBLEMATYKA ZAJĘĆ – dwie z trzech sfer:\nbudowa informatycznych systemów zarządzania w całości - od początku aż do oprogramowania całości – np. przez wyspecjalizowane firmy informatyczne, integracja już istniejących w organizacji systemów, pierwsza faza wdrażania istniejących, wcześniej zbudowanych systemów, czyli analiza i projekt zmian dostosowujących system do specyficznych warunków panujących w organizacji\n5 ANALIZA I PROJEKTOWANIE\nFragment cykl życia systemu rozpoczynający się od powstania pomysłu dotyczącego informatyzacji firmy aż do uruchomienia oprogramowania systemu informatycznego organizacji lub ostatecznej wersji oprogramowania w przypadku procesów przystosowawczych wdrażania systemu „gotowego”\n6 SYSTEM OBIEGU INFORMACYJNEGO\nOdzwierciedla wszystkie procesy materialne (dostarczenie materiałów, surowców, półproduktów, ich przepływ do produkcji, magazynowanie gotowych produktów, przekazanie ich odbiorcy itp.) i finansowe (obsługa zakupu, sprzedaż rozliczenia finansowe, analizy finansowe) zachodzące w danej organizacji\n7 SFERY SYSTEMU OBIEGU INFORMACYJNEGO\nSkodyfikowana (system norm, reguł, normatywów, praw, zarządzeń, standardów itp.), Nieskodyfikowana (system nieformalnych uzależnień, szantaż, oszustwo, plotki, łapówki, “dostępy” itp.)\n8 SFERY SYSTEMU OBIEGU INFORMACYJNEGO\nW systemie obiegu informacyjnego istnieją punkty decyzyjne, gdzie następuje transformacja informacji wejściowej na wyjściową, na podstawie określonych algorytmów. Algorytm występuje tutaj jako sformalizowany lub niesformalizowany opis czynności prowadzących do powyższego przekształcenia. Na wyższym poziomie abstrakcji algorytmem nazywa się też złożenie wszystkich algorytmów cząstkowych obrazujących ciąg decyzyjny odzwierciedlający przepływy informacyjne w systemie obiegu informacyjnego. Algorytmy obrazują system wielopłaszczyznowych, wzajemnych relacji pomiędzy punktami decyzyjnymi, sieć powiązań obrazuje strukturę przepływów informacyjnych w organizacji (strukturę systemu informacyjnego). Tworzony w organizacji system informatyczny powinien być nadbudową nad istniejącym systemem informacyjnym. Z tego punktu widzenia system informatyczny jest tą częścią systemu informacyjnego organizacji, która zostaje przystosowana do wspomagania zarządzania przy pomocy sprzętu komputerowego i telekomunikacyjnego oraz ludzi posiadających odpowiednie kwalifikacje, wyszkolonych dla jej obsługi.\n9 MIEJSCE SYSTEMU INFORMATYCZNEGO W ORGANIZACJI\nORGANIZACJA OTOCZENIE Sfera niesformalizowana Sfera sformalizowana System informatyczny System informacyjny ?\n10 PODSTAWOWE PROBLEMY Co stanie się gdy system informacyjny będzie zdegenerowany? Czy można informatyzować stadium zwyrodnienia systemu informacyjnego? Czy można informatyzować li tylko sferę skodyfikowaną? Czy etyczne jest informatyzowanie sfery nieskodyfikowanej? Czy możliwe jest wymuszenie powstania systemu informacyjnego na podstawie systemu informatycznego?\n11 PROBLEMY POCHODNE Czy skodyfikowano źródła wszystkich potrzebnych informacji? Czy obieg informacji skodyfikowanej dostosowany jest do potrzeb? Czy algorytmy (mentalne) i problemy decyzyjne są dobrze zdefiniowane? Czy mogą istnieć lepsze algorytmy? Czy istnieją algorytmy formalne rozwiązywania problemów decyzyjnych? Czy punkty decyzyjne są rozmieszczone w sferze skodyfikowanej?\n12 PRZEKROJE ANALIZY informacja potrzebna - informacja dostępna - decydentom dostarczana jest nadmiarowa ilość informacji tzn. informacje które nie są oni zdolni przetworzyć w czasie przed podjęciem decyzji, informacje w innym przekroju niż jest potrzebny do podjęcia decyzji, informacje wstępnie nieprzetworzone, informacje niepotrzebne, informacje niezrozumiałe lub błędne, algorytmy możliwe - algorytmy wykorzystywane - może się okazać, że istnieją szybsze algorytmy przetwarzania zadań decyzyjnych niż wykorzystywane, jeśli - z organizacyjnego może się okazać, że z całej gamy dostępnych algorytmów decyzyjnych dla prawidłowego działania organizacji wystarczy wykorzystywać tylko niektóre z nich, statyka - dynamika organizacji - problem nie sprowadza się do identyfikacji stanu bieżącego (wyodrębnienia obiektów, przepływów i relacji), a również identyfikacji sekwencji stanów w określonym czasie i powiązań pomiędzy obiektami dokonujących się w procesie dynamicznego rozwoju organizacji, integracja - dezorganizacja procesów informacyjnych w organizacji - każdemu wprowadzaniu innowacji do organizacji, towarzyszy ryzyko doprowadzenia organizacji do niezamierzonego chaosu . Stąd między innymi popularność systemów "całościowych", "zintegrowanych", "globalnych" itp.\n13 CECHY SYSTEMU INFORMACYJNEGO\nadekwatność treści i zakresu informacji do potrzeb danego szczebla zarządzania (w tym kodyfikacja części sfery nieskodyfikowanej na drodze szeroko pojętej restrukturyzacji lub reinżynierii) dostosowanie szybkości, częstości (dynamiki) i objętości informacji do cykli decyzyjnych dostosowanie kanałów przepływu informacji systemu informatycznego do struktury informacyjnej systemu informacyjnego komunikatywność form prezentacji informacji, nawet wbrew uprzednim wzorcom systemu informacyjnego aktualność informacji - opracowanie takich mechanizmów, które zapewnią dostarczanie informacji we właściwym czasie minimalizacja kosztu uzyskania i przechowywania informacji\n14 CECHY INFORMACJI dyspozycyjność - dostarczenie odpowiedniej ilości informacji w odpowiednim czasie porównywalność - odnosząca się do miar informacji oraz czasu jej dostarczenia wiarygodność - określenie źródeł, nadawców, kodów, translatorów itp. przetwarzalność - brak tolerancji dla danych przybliżonych częstotliwość - spływ odpowiedniego kwantum informacji w jednostce czasu\n15 FUNKCJE SYSTEMU INFORMACYJNEGO\nrozpoznawcze: ewidencja, identyfikacja i dystrybucja informacji modelowo-algorytmiczne: diagnoza, prognoza, symulacja, generowanie norm funkcjonowania organizacji regulacyjne: agregacja, dezagregacja, konfrontowanie, kontrola informacji\n16 PŁASZCZYZNY TRANSFORMACJI SYSTEMU INFORMACYJNEGO NA SYSTEM INFORMATYCZNY\nIdentyfikacji powtarzalnych, masowych, rutynowych czynności przetwarzania informacji Identyfikacji szczególnie złożonych informacyjnie i algorytmicznie kluczowych problemów decyzyjnych\n17 WNIOSEK: Stawką w grze - transformacji systemu informacyjnego w informatyczny - jest rzeczywiste włączenie systemu informatycznego w istotne problemy zarządzania organizacji i określenie jego miejsca w systemie zarządzania przeciwko automatycznemu kopiowaniu czynności przetwarzania tradycyjnego. Sukces tego przedsięwzięcia zabezpiecza przed fasadowością, pozoranctwem, skostnieniem i dezaktualizacją informacji używanej w procesie podejmowania decyzji.\n18 DEFINICJA SYSTEMU INFORMATYCZNEGO\n“ ... formalny, komputerowy system mający za zadanie udostępnienie, wybór i integrację danych pochodzących z różnych źródeł, w celu dostarczenia we właściwym czasie informacji niezbędnych do podejmowania decyzji zarządczych ...” Źródło: Turban E.: Decision Support and Expert Systems.Management Support Systems, Macmillan Publishing Company, New York, 1993, str. 29\n19 TYPOLOGIA SYSTEMÓW INFORMATYCZNYCH\nSystemy Transakcyjne Przetwarzania Danych - TPD - (Transaction Processing Data Systems - TPS), Systemy Automatyzacji Prac Biurowych i Inżynierskich - SAB - (Office Automation Systems - OAS, Computer Aided Design/Engineering - CAD/CAE), Systemy Informowania Kierownictwa - SIK - (Executive Information Systems - EIS), Systemy Informacyjne Zarządzania - SBD - (Management Information Systems-MIS), Systemy Wspomagania Decyzji - SWD - (Decision Support Systems -DSS), Systemy Eksperckie - SE - (Expert Systems -ES), Systemy Sztucznej Inteligencji - SSI - (Artificial Intelligence Systems - AIS)\n20 WSPIERANIE POZIOMÓW ZARZĄDZANIA PRZEZ SYSTEMY INFORMATYCZNE\n21 ZAŁOŻENIA PODEJŚCIA DO TWORZENIA SYSTEMÓW INFORMATYCZNYCH\nPodział całości na systemy, podsystemy i ich komponenty; wyróżnienie funkcji składowych tych elementów oraz relacji wzajemnych zachodzących pomiędzy nimi (co wynika bezpośrednio z analizy systemowej) traktowanie badanego procesu i formułowanego rozwiązania jako powiązanego ciągu wzajemnych relacji składających się dla każdego przedsięwzięcia z etapów: postawienia problemu, analiz, projektowania rozwiązań, programowania, wdrożenia i uruchomienia (co z kolei zapożyczone jest z systematyki badań operacyjnych)\n22 Porównanie: podejście naukowe, badań operacyjnych, analizy systemowej\n23 Słowo komentarza: Z powyższego zestawienia widać wyraźnie, że złożenie zasygnalizowanych metod stanowi podstawę nowoczesnej analizy systemowej i projektowania systemów informacyjnych i ich komputerowych odwzorowań, czyli systemów informatycznych Podczas budowy systemów informatycznych wspomagających zarządzanie organizacją zarówno z badań operacyjnych jak i analizy systemów zaczerpnięte zostały wszystkie elementy, które ten proces mogą w jakikolwiek sposób usprawnić, zmodyfikować, uprościć, połączyć w logiczna całość możliwą do objęcia przez osobę lub zespół osób tworzących system. Odbiciem tego procesu są również szczegółowe techniki analizy organizacji dostosowane lub przejęte bezpośrednio z metod analizy organizacji.\n24 Etapy tworzenia, wdrożenia i stabilizacji systemów informatycznych\nWycofywanie I Zmniejszenie funkcjonalności, ocena opłacalności\n25 ETAPY ROZWOJU SYSTEMÓW INFORMATYCZNYCH\nWstępne rozpoznanie 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.\n26 WSTĘPNE ROZPOZNANIE SYSTEMU- ETAPY\n27 KRYTERIA OCENY SYSTEMU\norganizacyjnych użyteczność - procent pokrycia funkcji użytkowych organizacji, stopień wykorzystania przez personel, stopień integracji organizacji, ekonomicznych koszty - operacyjne, eksploatacyjne, jednostkowe, efekty - organizacyjno-ekonomiczne, zyski - szybkość i miara zyskowności, technologicznych 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, psychologicznych stopień akceptowalności przez pracowników, potencjalne bariery wdrożeń, potencjalne metody usuwania zagrożeń systemu.\n28 KOSZTY I NAKŁADY koncepcję, analizę, projektowanie systemu,\nprzygotowanie 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.\n29 POTENCJALNE EFEKTY Z INFORMATYZACJI\n30 OCENA EKONOMICZNA INWESTYCJI INFORMATYCZNYCH\nokres 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 inwestycjit = Zyskt/Kosztt*Dt gdzie: Dt - współczynnik dyskonta w okresie t, t - czas\n31 ZAŁOŻENIA INFORMATYZACJI – końcowy dokument fazy wstępnej\n1. 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\n32 ANALIZA INFORMACYJNA SYSTEMU- fazy\n33 SCHEMAT ANALIZY ORGANIZACYJNEJ\n34 RAPORT "ANALIZA ORGANIZACYJNO-INFORMACYJNA"\n35 RAPORT "ANALIZA ORGANIZACYJNO-INFORMACYJNA"\nOkreś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łu danych, topologii sieci, mediów przesyłu 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.\n36 TWORZENIE PROJEKTU TECHNICZNEGO SYSTEMU\n37 PROJEKT LOGICZNY A FIZYCZNY\n38 ZAWARTOŚĆ PROJEKTU TECHNICZNEGO\n1. Charakterystyka ogólna systemu - jego cele działania, ograniczenia, struktura, schemat logiczny przepływów danych (schemat blokowy lub inne metody) 2. Specyfikacja oprogramowania - zalecenia dotyczące oprogramowania dla systemu. 3. Specyfikacja mediów obsługi danych - dokładna postać i obsługa formatek ekranowych, dokumentów wejściowych i wynikowych, raportów itp. 4. 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. 5. Specyfikacja transferu danych - określenie topologii sieci, mediów przesyłu danych, formatu przepływu oraz urządzeń towarzyszących 6. 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 7. Rozmieszczenie i wymagania względem personelu 8. Specyfikacja wdrożenia - wnioski dotyczące instalacji i szkolenia przyszłych użytkowników systemu, harmonogram wdrożenia i szkoleń\n39 NASTĘPNE FAZY ROZWOJU SYSTEMU\n40 NASTĘPNE FAZY ROZWOJU SYSTEMU\n41 CYKL ŻYCIA SYSTEMU INFORMATYCZNEGO\n42 ETAPY CYKLU ŻYCIA SYSTEMU INFORMATYCZNEGO\n43 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.\n44 Tradycyjne modele cyklu życia systemu informatycznego\n45 TRADYCYJNE MODELE CYKLU ŻYCIA SYSTEMU\n46 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\n47 MODEL KASKADOWY (LINIOWY)\n48 MODEL EWOLUCYJNY Cały system jest dzielony na moduły\n49 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\n50 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\n51 MODEL PRZYROSTOWY E k s p l o a t c j Testowanie2 I n s t a l c j W d\n52 MODEL TWORZENIA STRUKTURY BAZ DANYCH\n1. Rozpoznanie i analiza - zebranie potrzeb informacyjnych użytkowników 2. 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\n53 MODEL TWORZENIA STRUKTURY BAZY DANYCH\n54 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)\n55 MODEL Z TWORZENIEM PROTOTYPU\n56 MODEL SPIRALNY 1. Budowę modelu rozpoczyna się od ustalenia wstępnych wymagań i analizy ryzyka ich realizacji 2. Na tej podstawie buduje się pierwszy prototyp i tworzy konceptualny plan całości 3. Po kolejnej fazie analizy ryzyka oraz zbadania ewentualnych alternatyw budowany jest następny prototyp i tworzy się wymagania dotyczące oprogramowania 4. Powstaje plan tworzenia i odbywa się kolejny etap zakończony projektem oprogramowania 5. Kolejny obieg przynosi projekt szczegółowy, oprogramowanie, testy i wdrożenie\n57 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\n58 KLASYCZNE TECHNIKI GROMADZENIA INFORMACJI\n59 METODA A TECHNIKA Metoda - logicznie powiązany ciąg czynności (postępowania) prowadzący do osiągnięcia założonych celów. Poszczególne metody na ogół składają się z wielu wspólnych sobie lub różnych, wspomagających je technik szczegółowych. Technika - szczegółowe środki i narzędzia realizacji używane w ramach założonej metody działania\n60 TECHNIKI ZBIERANIA DANYCH OD UŻYTKOWNIKA\nosobiste wywiady ankiety (kwestionariusze) obserwacja uczestnicząca badanie dokumentów, raportów, zbiorów danych, sprawozdań, „ręcznych” procedur przetwarzania, sprawdzanie statystyk finansowych i sprawozdań księgowych\n61 WYWIADY Technika gromadzenia informacji drogą wywiadu polega na przeprowadzeniu bezpośredniej rozmowy z osobą, która może nam jej dostarczyć. Od osoby "przepytywanej" spodziewamy się uzyskać jej opinie i odczucia dotyczące obecnego stanu systemu, celów organizacji jako całości i celów działania jej poszczególnych członków i zespołów - całej sformalizowanej i niesformalizowanej sfery informacyjnej przedsiębiorstwa. Wywiad może mieć postać bezpośredniej rozmowy (rejestrowanej lub nie rejestrowanej) albo opierać się na specjalnie w tym celu przygotowanych pytaniach lub nawet kwestionariuszach. Powinien być starannie przygotowany, sytuacja jednak może wymagać czasami przeprowadzenia wywiadu ad hoc. W przygotowaniu wywiadu można wyróżnić następujące kroki: Zapoznanie się z dostępnym materiałem na temat organizacji (artykuły prasowe, strona internetowa, publikowane raporty roczne, materiały handlowe lub nawet osoby, z którą wywiad ma być przeprowadzany (opinie przełożonych, podwładnych, znajomych, artykuły prasowe itp.). Znajomość takich faktów ułatwia zrozumienie polityki organizacji, stawianie właściwych pytań, skraca czas wywiadu i wyrabia przekonanie o znajomości tematu przez przeprowadzającego wywiad.\n62 WYWIADY Ustalenie celów wywiadu - trzeba zdefiniować sobie około pięciu kluczowych (podstawowych) dziedzin dotyczących przetwarzania informacji oraz procesu podejmowania decyzji, w których będzie się stawiało pytania (np. źródła informacji, częstotliwość podejmowania decyzji, format dokumentów, jakość informacji, styl podejmowania decyzji itp.). Wskazanie osoby udzielającej wywiadu - może odbywać się poprzez wskazanie przez osobę pierwszego kontaktu, może to być osoba wyselekcjonowana droga przypadku lub jej nazwisko może wynikać z wcześniej przeprowadzonych rozmów. Powinna to być zasadniczo osoba nie tyle stojąca najwyżej w hierarchii danej organizacji co "kluczowa" - która wie o danej organizacji lub jej szczególnej działalności stosunkowo najwięcej (pracowała najdłużej, jest nieformalnym ekspertem organizacji, pracowała na wielu stanowiskach, orientuje się w całej polityce organizacji itp.). Przygotowanie wskazanej osoby do udzielenia wywiadu - jeżeli wyniki wywiadu mają być konkretne i zawierać również fakty, a nie przypadkowe opinie dobrze jest nie zaskakiwać osoby, z która przeprowadzamy wywiad i ja o tym uprzedzić za pomocą telefonu, poczty elektronicznej zapowiadając temat wywiadu i podstawowe tezy (ewentualnie potrzebne materiały dodatkowe) aby miała czas na przemyślenie i przygotowanie się do rozmowy, ustalić czas i miejsce przeprowadzenia oraz środki, które będą używane do utrwalenia wyników wywiadu.\n63 Przygotowanie kwestionariusza pytań otwartego\n64 Przygotowanie kwestionariusza pytań zamkniętego\n65 KWESTIONARIUSZE Technika która pozwala analitykowi rozpoznawać cechy charakterystyczne, zachowania zarówno obecnego systemu jak i pracowników organizacji oraz ich potencjalny wpływ na planowany system informatyczny. Użycie kwestionariuszy jest opłacalne w przypadku gdy: ludzie, których chcesz pytać są rozproszeni terytorialnie lub pracują w różnych gałęziach w ramach tej samej korporacji, wiele osób z informatyzowanej organizacji jest włączonych w projekt i chcemy poznać ich opinię na temat różnych szczególnych cech systemu, dotyczących dziedziny, którą się oni zajmują, realizowana jest początkowo w ramach rozpoznania systemu tylko koncepcja wstępna, decyzje co do nadania systemowi specyficznego kierunku mają zapaść później, na podstawie tejże koncepcji, chcesz mieć pewność, że każdy problem jaki się pojawia w bieżącej organizacji zostanie rozpoznany. Największa różnica występująca pomiędzy pytaniami występującymi w wywiadach i w kwestionariuszach polega na tym, że wywiady pozwalają na interakcję pomiędzy pytaniami i uzyskiwanymi w ich wyniku odpowiedziami.\n66 Pytania otwarte Nie mogą to być pytania zbyt szerokie ponieważ później trudno jest odpowiedzi na nie ocenić i ewentualnie skwantyfikować dla celów porównawczych np. Jakie są Twoje doświadczenia związane z obecną postacią systemu? Jest to pytanie za szerokie i należy je w specjalny sposób zawęzić tak aby dać respondentowi możliwość jednoznacznej wypowiedzi np. ustawić je w płaszczyźnie: Czy jesteś usatysfakcjonowany z obecnego systemu? Jeżeli nie to podaj główną przyczynę Twojego niezadowolenia? Przykładem pytań w kwestionariuszu otwartym mogą też być kwestie następujące: Jakich najczęściej doświadczasz problemów z dokumentami wejściowymi z systemu, który obsługujesz? Spośród problemów wymienionych powyżej, który jest najbardziej poważny? Dlaczego wymieniłeś właśnie ten problem? Jak długo pracujesz w tej firmie? Jak długo pracujesz w tej samej gałęzi przemysłu? W jakich jeszcze gałęziach przemysłu pracowałeś?\n67 Pytania zamknięte Przykłady formy pytań w kwestionariuszu zamkniętym:\nZaznacz, które z programów pakietów biurowych są wykorzystywane przez Ciebie na Twoim stanowisku pracy: Microsoft Word Excel Access Power Point Outlook Wydruki dotyczące sprzedaży opóźniają się (zaznacz właściwą odpowiedź): nigdy wyjątkowo rzadko często zawsze Jednostka, w której aktualnie pracuję nazywa się: marketing płace kadry sprzedaż\n68 Odpowiedzi w kwestionariuszu zamkniętym mogą być oceniane w skali:\nnominalnej - pozwalającej klasyfikować rzeczy przez dokonywanie wyboru, porządkującej - ze skalą ważności, ustawiające w określonym porządku, przedziałowej - ustalana jest skala podziału pomiędzy wartościami krańcowymi, wskaźnikowej - skala podziału zawiera zero i przedziały nie muszą być równe tak jak w przedziałowej.\n69 Rozprowadzanie kwestionariuszy\ndostarczenie zgromadzonym respondentom w jednym miejscu i czasie, własnoręczne wręczenie pustych kwestionariuszy i własnoręczne odebranie, odbiór kwestionariuszy z odpowiedniego departamentu (np. organizacyjno-prawnego), wysłanie ich pocztą, wraz z instrukcja wypełnienia, terminami i adresem zwrotnym, rozdysponowanie elektroniczne lub umieszczenie kwestionariusza na określonej stronie internetowej.\n70 Obserwacja uczestnicząca\nTechnika pozwalająca na obserwację menedżerów i sposobów podejmowania przez nich decyzji w otoczeniu organizacyjnym. Pozwala poznać firmę nie tylko z zewnątrz na podstawie obcych obserwacji i wynikających stąd dokumentów, ale także być wewnątrz tego co się dzieje i uzyskiwać je niejako z pierwszej ręki. Obserwator decyduje o informacjach o relacjach organizacyjnych jakie w danej chwili chce uzyskać. W swoim postępowaniu obserwator powinien na początku rozpatrzyć: Jakie dziedziny działalności firmy będzie chciał obserwować, Na jakim szczeblu abstrakcji, czy poprzestanie na informacjach typu co? Czy też zejdzie na poziom dlaczego, w jaki sposób i w jakiej ilości? Za pomocą jakich kategorii będzie oceniał działalność? Za pomocą jakich dodatkowych technik czy narzędzi przeprowadzi analizę? Jak powinny być skonstruowane? Kiedy przeprowadzi obserwację (harmonogram)? Obserwacja pozwala także na ocenę psychologiczna osób podejmujących decyzje w ich miejscu pracy, czego nie umożliwiają inne techniki badawcze. Obserwacja uczestnicząca pozwala więc na pełniejszy obraz rzeczywistości jaka ma być modelowo ujęta w postaci systemu informacyjnego i umożliwia przedstawienie koncepcji wstępnej o wiele lepiej przystającej do rzeczywistości niż w przypadku innych technik badawczych\n71 Analiza dokumentacyjna\nTechnika zbierana danych, która jest niezbędna przy analizie i budowie każdego systemu informatycznego, najlepsze rezultaty dając w połączeniu z innymi technikami. Jest niezbędna przy ocenie zapotrzebowania informacyjnego wynikającego z obiegu dokumentów w organizacji, ocenie zawartości i konstruowaniu następnie zawartości bazy danych, odwzorowaniu dokumentacji wejściowej i raportów wyjściowych itp. Na podstawie analizy dokumentacyjnej można też wyrobić sobie pogląd na kondycję firmy a nawet stosunki panujące w organizacji. W sumie nikt nie podważa istotności tej techniki w analizie organizacji, natomiast ma jedną zasadniczą wadę - nie daje pojęcia o ogólnej strukturze działania organizacji, przepływach informacyjnych i punktach decyzyjnych.\n72 Przykładowa lista pytań analitycznych\nZ punktu widzenia danych, które funkcjonują w systemie można w nim wymienić następujące sfery modelowe: informacji wejściowych - w jakich dokumentach, jak przetwarzanych, o jakiej dokładnej postaci dane występują i jakim procesom wstępnym podlegają, przetworzenia - transformacji informacji wejściowych w wyjściowe - dotyczy podstawowych algorytmów i metod ich obsługi, informacji wyjściowych - obsługa raportów wynikowych, gromadzenia informacji - umiejscowienie, postać i struktura bazy (baz) danych, przepływu informacji - powiązań pomiędzy punktami przetwarzania w systemie, kontroli informacji we wszystkich sferach działania systemu.\n73 Informacja w procesie zarządzania\nORGANIZACJA Przesyłanie Kontrola Wejście Przetwarzanie Wyjście Gromadzenie\n74 Wejście: W jaki sposób dane będą wprowadzane do systemu?\nCzy w formie zbliżonej do dokumentu źródłowego, czy też dokument stanowić będzie tylko podstawę do zasilania poprzez własne formatki ekranowe systemu? Czy można rozważać wprowadzanie danych przez dodatkowe środki techniczne np. skanery czy też czytniki dokumentów, czytniki kodów paskowych? Czy dane wejściowe będą gromadzone w postaci zbiorów i dopiero przetwarzane (przetwarzanie batch'owe), czy też muszą być przetwarzane w trybie natychmiastowym? Czy wymagane jest wstępne sortowanie danych wejściowych? Jeżeli tak - to jaka jest lista kryteriów? Jakie różnice w ilości, szybkości przetworzenia, wolumenie danych występują w systemie (minimalna, przeciętna, maksymalna)? Czy możliwa jest wstępna obróbka przetworzonych danych przez osoby, które te dane wprowadzają? Czy w trakcie wprowadzania danych będą potrzebne procedury kodowania, klasyfikacji i edycji, a jeżeli tak, to jakie? Jakie procedury kontroli będą użyte dla zapewnienia poprawności wprowadzanych danych? Czy format i procedury wprowadzania danych będą przystosowane do ewentualnych zmian w organizacji (przewidywanych, planowanych)? Jaka musi być elastyczność systemu?\n75 Przetwarzanie: Jaki rodzaj przetwarzania (sortowanie, przeliczanie, porównywanie, sumowanie, agregacja itp.) w stosunku do jakich dokumentów powinien być zastosowany? Które z tych procedur powinny być wykonywane automatycznie, a które pod kontrolą użytkownika? Które z nich wymagają przetworzenia natychmiastowego? Jaki model przetworzenia danych ma być zastosowany (sieć Novella, zintegrowana baza danych, rozproszona baza danych, jednostanowiskowy)? Czy procedury i metody przetworzenia zapewniają terminową i odpowiednio ilościową obsługę wyjścia? Czy zastosowane procedury i algorytmy nie ograniczają wzrostu systemu? Jaki zakres interwencji użytkownika w trakcie przetwarzania jest konieczny w systemie? Jakie dokumenty i procedury kontroli są wbudowane w system?\n76 Wyjście: Czy dokumenty wyjścia mają być prezentowane w formie drukowanych dokumentów i raportów, czy też mają być wyświetlane na ekranie? A może na oba sposoby? W jakiej formie? Czy dane wyjściowe, a jeżeli tak to jaki, mają być prezentowane w formie czytelnej dla maszyny (zbiór dyskowy, dyskietka, czytnik) ? Czy wyjście z naszego systemu ma stanowić wejście do systemu innego? Czy informacje na wyjściu mają się pojawiać w trybie natychmiastowym? Czy na wyjściu ma się pojawiać informacja o każdej dokonanej transakcji, czy tylko o wyjątkowych (o jakich i w jakich sytuacjach)? Czy dokumenty wyjścia maja być generowane na żądanie, tak jak wcześniej zaplanowano, czy tylko w wyjątkowych przypadkach? Czy są konieczne jakieś zewnętrzne procedury wspomagające (kopiowanie, mikrofilmowanie, skanowanie)? Czy będą to dokumenty dla użytkowników wewnętrznych czy zewnętrznych (jakie, co ile)? Czy istniejące formaty i częstotliwość wyjściowych dokumentów zapewniają terminowe i pełne zaspokojenie potrzeb użytkownika? Czy jakieś raporty mogą być zestandaryzowane, skonsolidowane lub usunięte? Jakie procedury kontrolne zapewniają terminowe i pełne zaspokojenie potrzeb użytkownika? Czy planowane formy wyjścia będą na tyle elastyczne by zapewnić rozwój systemu?\n77 Gromadzenie: Czy istniejący system używa zintegrowanej bazy danych czy bazy danych rozproszonych? Czy dane w istniejących bazach danych powtarzają się (w jakim zakresie oraz przekrojach)? Które z nich mogą być przechowywane w sekwencyjnych zbiorach danych (archiwizowane)? W jaki sposób baza danych powinna być zorganizowana? Z jakich elementów powinna się składać (rekordy, pola, znaki)? Czy przewidywany jest bezpośredni dostęp do zbiorów bazy danych, czy też poprzez zbiory tymczasowe? Czy zbiory danych mogą być zmieniane w interakcyjnym procesie konwersacji z użytkownikiem? Jakie są kryteria niszczenia bądź przemieszczania danych pomiędzy zbiorami? Czy dotychczasowe procedury kontroli wbudowane w celu zmniejszenia nieautoryzowanych wejść do systemu nie ogranicza w zasadniczy sposób możliwości korzystania z tego systemu? Czy gromadzenie danych jest elastyczne, czy też bierze pod uwagę możliwości zmian w typie, rozmiarze, wolumenie i częstotliwości pojawiających się danych, możliwości zmian organizacyjnych, czy możliwości zmian otoczenia, w którym działa organizacja?\n78 Przesyłanie: Czy system ma być jednostanowiskowy czy wielostanowiskowy i pracować w sieci? Jakie media mają system obsługiwać (skrętka, koncentryk, światłowód, fale radiowe)? Jaka zostanie przyjęta w realizacji topologia systemu i dlaczego? Na jakiej płaszczyźnie ma pracować system? Jakie protokoły będą system obsługiwać? Jakie będzie "geograficzne" umiejscowienie poszczególnych stanowisk systemu? Jak to jest związane z systemem informacyjno-organizacyjnym firmy oraz kolejnymi podsystemami systemu? Czy i z jakimi systemami nasz system będzie połączony siecią? Czy system będzie połączony z systemami globalnymi, w tym z internetem? Jakie będą metody kontroli dostępu do sieci? Jak zagwarantowane będzie bezpieczeństwo sieci?\n79 Kontrola: Czy dotychczasowe metody kontroli wejścia/wyjścia wykrywają błędne lub niedokładne dane zawarte w systemie? Czy mechanizmy kontroli procedur przetwarzania są także w stanie to zrobić? Czy informacje o wykrytych błędach są natychmiast sygnalizowane, czy zapisywane w odpowiednich zbiorach i udostępniane osobom odpowiedzialnym za kontrolę? Czy procedury kontroli zapewniają odpowiednie zabezpieczenie tajności (dyskrecji) przechowywanych danych? W jaki sposób dane mają być archiwizowane? Z jaką częstotliwością, na jakich mediach, jakie mechanizmy dostępu będą stosowane? Jakie mechanizmy zapewniają poprawne działanie systemu w niekorzystnych warunkach technicznych? Czy mechanizmy kontroli systemu mogą być niezależne od użytkownika? Czy mechanizmy kontroli obejmują procedury ewolucji systemu?\n80 METODY ANALIZY I PROJEKTOWANIA\n81 TYPOLOGIA METOD ANALIZY I PROJEKTOWANIA\n82 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\n83 Analiza w podejściu strukturalnym\n84 Projektowanie w podejściu strukturalnym\n85 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.\n86 Grupy metod obiektowych\n87 Etapy w metodach obiektowych\n88 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\n89 Etapy w metodach operacyjnych\n90 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.\n91 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)\n92 Fazy w metodach społecznych\n93 Porównanie metod strukturalnych i obiektowych\n94 Porównanie metod strukturalnych i obiektowych\n95 Porównanie metod strukturalnych i obiektowych\n96 Porównanie metod strukturalnych i obiektowych\n97 Cechy charakterystyczne metod tradycyjnych\n98 Cechy charakterystyczne metod tradycyjnych\n99 Cechy charakterystyczne metod tradycyjnych\n100 Nowoczesne metody projektowania systemów informatycznych\n101 Dwanaście zasad tworzenia zwinnego oprogramowania\n102 Założenia metodyk nowoczesnych (zwinnych)\n103 Założenia metodyk nowoczesnych (zwinnych)\n104 Założenia metodyk nowoczesnych (zwinnych)\n105 Założenia metodyk nowoczesnych (zwinnych)\n106 Założenia metodyk nowoczesnych (zwinnych)\n107 Nowoczesne (zwinne, lekkie) metody projektowania\n108 Założenia i zalecenia metodyki XP\n109 Założenia i zalecenia metodyki XP\n110 Założenia i zalecenia metodyki XP\n111 Założenia i zalecenia metodyki XP\n112 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,\n113 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.\n114 Podstawowe fazy cyklu życia projektu w modelu XP\n115 SCRUM – praktyki projektowania\n116 SCRUM – praktyki projektowania\n117 Cykl życia w metodzie Scrum\n118 Cykl życia systemu informatycznego w metodyce Scrum\n119 Cykl życia systemu informatycznego w metodyce Scrum\n120 Założenia metodyki Feature Driven Development (FDD)\n121 Założenia metodyki Feature Driven Development (FDD)\n122 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,\n123 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.\n124 Fazy cyklu życia FDD\n125 Dynamic System Development Method (DSDM)\n126 Dynamic System Development Method (DSDM)\n127 Dynamic System Development Method (DSDM)\n128 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.\n129 Cykl życia DSDM\n130 Metoda Adaptive Software Development - ASD\n131 Metoda Adaptive Software Development - ASD\n132 Metoda Adaptive Software Development – ASD – cykl życia\n133 Metoda Adaptive Software Development – ASD – cykl życia\n134 Podobieństwa metod tradycyjnych i nowoczesnych\n135 Pokrycie faz cyklu życia przez poszczególne metody\n136 Czynniki decydujące o zastosowaniach nowych rozwiązań\n137 Czynniki decydujące o zastosowaniach nowych rozwiązań\n138 Czynniki decydujące o zastosowaniach nowych rozwiązań\n139 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,\n140 Czynniki decydujące o zastosowaniach nowych rozwiązań\n141 Porównanie sukcesu projektów realizowanych za pomocą metod tradycyjnych i nowoczesnych\n142 Kierunki rozwoju metodyk projektowania systemów informatycznych\n143 Metodyka Project Management Institute (PMI)\nPierwszy, wiodący i najbardziej abstrakcyjny w sensie ideologicznym uważany jest produkt PMI - PMBOK Guide (ang. A Guide to the Project Management Body of Knowledge), wydany początkowo w 1983 r. jako tzw. biała księga, w 1996 roku jako oficjalne wydanie pierwsze, 2000 r. drugie, piąte wydanie jest planowane na 2013 r. Jest on zbiorem wciąż uzupełnianym standardów i rozwiązań w dziedzinie zarządzania projektami, wykonanym i opublikowanym przez członków PMI (Project Management Institute). Standard PMBOK Guide to zbiór powszechnie uznanych praktyk znajdujących zastosowanie w zarządzaniu projektami. Dokument ten grupuje procesy dotyczące zarządzania projektami w pięć grup procesów (z podprocesami) i dziewięć obszarów wiedzy. Ze względu na brak wymogu sekwencyjności procesów w projekcie grupy procesów, choć prezentowane w określonej kolejności, mogą nachodzić na siebie w trakcie projektu.\n144 Grupy procesów i odpowiadające im podprocesy\nProcesy rozpoczęcia - procesy, które służą zdefiniowaniu i zatwierdzeniu projektu lub jego etapu w organizacji. W tym podprocesy: opracowanie dokumentu otwarcia, opracowanie wstępnego zakresu projektu, Procesy planowania - określanie i precyzowanie celów projektu oraz wybór najlepszego z dostępnych sposobów działania, pozwalających osiągnąć cele projektu – są to procesy odpowiadające na pytanie: jak, w jaki sposób zrealizować zamierzone cele, jakimi środkami, kiedy, w jakiej kolejności itp. W tym podprocesy: opracowanie planu zarządzania projektem, planowanie zarządzania zakresem projektu, definiowanie zakresu projektu, opracowanie struktury podziału prac, zdefiniowanie czynności, porządkowanie czynności, szacowanie zasobów czynności, szacowanie czasu trwania czynności, opracowanie harmonogramu, szacowanie kosztów, budżetowanie kosztów, planowanie jakości, planowanie zasobów ludzkich, planowanie komunikacji, planowanie zarządzania ryzykiem, identyfikacja ryzyka, jakościowa analiza ryzyka, ilościowa analiza ryzyka, planowanie reakcji na ryzyko, planowanie zaopatrzenia, planowanie kontraktów,\n145 Grupy procesów i odpowiadające im podprocesy\nProcesy realizacji - koordynacja ludzi i innych zasobów w celu wykonania przyjętego planu. W tym podprocesy: kierowanie i zarządzanie realizacją projektu, zapewnienie jakości, przyjmowanie członków zespołu, rozwój zespołu, dystrybucja informacji, gromadzenie ofert od sprzedawców, wybór sprzedawców, Procesy kontroli - dbałość o realizację celów projektu poprzez systematyczne monitorowanie i mierzenie wykonania projektu, pozwalające na wykrycie odchyleń od planu i podjęcie działań korygujących. W tym podprocesy: monitorowanie i nadzór nad pracami projektu, zintegrowane zarządzanie zmianami, weryfikacja zakresu, sterowanie zakresem, nadzór nad harmonogramem, nadzór nad kosztami, kontrola jakości, zarządzanie zespołem, raportowanie postępu prac, zarządzanie udziałowcami (interesariuszami), monitorowanie i nadzór nad ryzykiem, administrowanie kontraktem, Procesy zakończenia - formalna akceptacja rezultatów uzyskanych w projekcie lub w danych etapie projektu oraz prawidłowe zakończenie projektu lub jego etapu. W tym podprocesy: zamknięcie projektu, zamknięcie kontraktu\n146 Obszary wiedzy projektu\nzarządzanie integracją projektu, zarządzanie zakresem projektu, zarządzanie czasem w projekcie, zarządzanie kosztami projektu, zarządzanie jakością w projekcie, zarządzanie zasobami ludzkimi w projekcie, zarządzanie komunikacją w projekcie, zarządzanie ryzykiem w projekcie, zarządzanie zamówieniami w projekcie.\n147 Obszary PMI Obszar zarządzania integralnością projektu - obejmuje opracowanie planu projektu, realizację planu projektu oraz zintegrowaną kontrolę zmian. W PMBOK występuje specyfikacja informacji wejściowych dla tworzenia planu projektu, tak by stanowił integralna całość i był zgodny z pozostałymi przedsięwzięciami realizowanymi w organizacji. Analiza tych informacji (istniejąca dokumentacja, informacja historyczna, wytyczne organizacyjne, ograniczenia w realizacji projektu, założenia projektowe) nie obejmuje jednak procesów biznesowych i ich wpływu na przebieg projektu nowego systemu. Zarządzanie zakresem projektu – w skład którego wchodzi: zapoczątkowanie projektu, planowanie zakresu, doprecyzowanie zakresu, weryfikacja zakresu projektu oraz kontrola zmian zakresu. Brak zarządzania integralnością projektu w odniesieniu do przebiegu procesów również skutkuje brakiem integralności zarządzania zakresem (a więc i wymaganiami) z przebiegiem biznesowych procesów organizacji.\n148 Obszary PMI Zarządzanie czasem trwania projektu – składające się z: identyfikacja działań, określania kolejności działań, estymacji czasu trwania działań, opracowywaniu harmonogramu i kontroli harmonogramu. Brak jest wytycznych aby w każdej z powyższych kategorii należało przeprowadzić analizę wpływów i zależności, odniesionych do przebiegu procesów biznesowych organizacji. Czasami uwzględnienie okoliczności wynikających z przebiegu procesów będzie bardziej oczywiste (np. proces księgowań i zamknięcia roku bywa zwykle brany pod uwagę przy planowaniu wdrożeń systemów księgowych), lecz zachodzący w zupełnie innym obszarze firmy proces cyklicznie przeprowadzanej akcji marketingowej, powodujący zwiększoną ilość księgowań wpływających na zaangażowanie zasobów projektowych, może już nie być dla osób biorących udział w zarządzaniu czasem projektu tak oczywisty\n149 Obszary PMI Zarządzanie kosztami projektowymi – zawierające: planowanie zasobów, estymację kosztów, budżetowanie kosztów i kontrolę kosztów. PMBOK dostarcza szczegółowych wytycznych zarządzania tym obszarem, jako, że stanowi on jeden z najważniejszych elementów każdego projektu. Nałożenie planowanych kosztów osobowych na ogólną mapę przebiegu procesów biznesowych organizacji może jednak dostarczyć bardzo cennej wiedzy o planowanym rozpoczęciu procesu szkolenia, co może wpłynąć na np. konieczność zapłaty nadgodzin. Czynnik kosztowy ma też znaczenie przy analizie opłacalności projektu, która poprzedza zwykle decyzję o jego rozpoczęciu. Zarządzanie jakością – obejmujące planowanie jakości, zapewnianie jakości i kontrolę jakości. PMBOK zaleca ciągłą analizę produktów projektowych pod kątem jakości. Jednak każdy projekt powinien zostać osadzony we wcześniej przyjętych miernikach jakości procesu zarządzania projektem. W zależności od nich, za dobry jakościowo projekt może zostać uznany ten, który doprowadził do zakładanego wsparcia procesów biznesowych lub ten, który pozostawił pewne założenia funkcjonalne niezrealizowane, ale zakończył się w przewidywanym terminie i wyznaczonym budżecie.\n150 Obszary PMI Zarządzanie zasobami ludzkimi – składające się z podobszarów planowania organizacyjnego, pozyskiwania personelu i kształtowania zespołu. Zgodnie z PMBOK członkowie zespołu projektowego powinni posiadać odpowiednią wiedzę, doświadczenie, dobre cechy interpersonalne, pasującymi do całości zespołu. Jak również być odpowiednio zmotywowani do realizacji projektu. PMBOK proponuje kształtowanie zespołu projektowego przez pryzmat umiejscowienia funkcjonalnego w strukturach przedsiębiorstwa. Dostarczyć to ma, według omówionej metodyki, siły odpowiednio wykwalifikowane do realizacji konkretnego projektu kształtowanie zespołów na bazie kompetencji funkcyjnych ich członków i obsadzanie kluczowych ról informatykami powoduje, że projekty wdrożeń informatycznych realizowane są przez zespoły cechujące się brakiem zainteresowania sukcesem projektu, ponieważ nie mają możliwości poprawy procesów biznesowych, w których uczestniczą.\n151 Obszary PMI Zarządzanie komunikacją – na które składa się : planowanie komunikacji, dystrybucja informacji, sprawozdawczość wyników oraz zamknięcie administracyjne. Metodyka PMBOK zakłada, że w projekcie zostaną wytworzone kompetencje zapewniające komunikację wewnętrzną oraz zewnętrzną decyzji podejmowanych w projekcie, postępów prac projektowych i przekazywanie innych informacji umożliwiających wpływ na otoczenie projektu\n152 Obszary PMI Zarządzanie ryzykiem – w skład którego wchodzi: planowanie zarządzania ryzykiem, identyfikacja ryzyka, jakościowa analiza ryzyka, ilościowa analiza ryzyka, planowanie reakcji na ryzyko oraz monitorowanie i kontrola ryzyka. PMBOK określa ryzyko jako wszelkie wydarzenia, które mogą negatywnie wpłynąć na realizację projektu, zarówno ze względu na zdarzenia wewnętrzne i zewnętrzne. Wśród nich wyróżnia zdarzenia niepozwalające wykorzystać wszystkich możliwości projektowych oraz negatywnie wpływające na zaplanowane działania. Na identyfikację ryzyka wpływają: tolerancja interesariuszy projektu na negatywne zdarzenia, zidentyfikowane źródła ryzyka, potencjalne zdarzenia inicjujące wystąpienie ryzyka, szacunki kosztów wystąpienia ryzyka oraz wpływ tych czynników na harmonogram projektu. W PMBOK występują zaawansowane analitycznie metodyki w zakresie oceny prawdopodobieństwa wystąpienia ryzyka i analizy planów zapobiegających i naprawczych.\n153 Obszary PMI Zarządzanie zamówieniami – zawierające: planowanie zamówień, planowanie zapytań, zebranie ofert, wybór dostawców, administracja kontraktem oraz zamknięcie kontraktu. PMBOK dostarcza wnikliwej metodyki w zakresie procesu realizacji zamówień. Zasadniczo można ją wykorzystać we wszystkich procesach zakupowych przedsiębiorstwa. Na ogół jednak firmy posiadają już rozwinięte procedury zamówieniowe i to właśnie zarządzanie projektem musi je uwzględniać, a nie odwrotnie.\n154 Metodyka Modelu Poziomów Dojrzałości (CMM - Capability Maturity Model) oraz Zintegrowanego Modelu Poziomów dojrzałości (CMMI - Capability Maturity Model Integration Model CMI powstał na zlecenie Departamentu Obrony USA dla rozwiązania problemów związanych z jakością oprogramowania tworzonego no ich potrzeby w latach osiemdziesiątych dwudziestego wieku. Ze względu na subiektywnie narzuconą pięciostopniowa skalę dojrzałości do modelu tego zgłaszano liczne zastrzeżenia. Dlatego był nieustannie rozwijany, co w latach dziewięćdziesiątych zaowocowało stworzeniem systemu zintegrowanego, którego postać z 2006 r. (CMMI – DEV (for Development)) zawiera dwie poprzednie wersje ciągła (CMMI -CR – Continous Representation) i etapową (CMMI – SR – Staged Representation). CMMI – DEV należy traktować jako zestaw najlepszych praktyk służących do tworzenia i wykorzystania oprogramowania, w całym cyklu życia produktu od powstania koncepcji, projekt, oprogramowanie, wdrożenie, po dostarczenie i utrzymanie. W obecnym modelu rozszerzonym (IPPD - Integrated Product and Process Development) rozpatrywana jest również rola zespołów projektowych w procesach zintegrowanych. Metoda służy do całościowej oceny tworzenia i zastosowania oprogramowania dla organizacji poprzez zakwalifikowanie jej na jeden z pięciu (reprezentacja etapowa) lub sześciu (reprezentacja ciągła) poziomów dojrzałości\n155 W modelu o reprezentacji etapowej są one następujące:\nPoziom 1. Początkowy (Wstępny - ang. Initial) – firma podejmuje wysiłki w celu zarządzania projektami IT (projektowanie, rozwój, integrowanie, testowanie), Poziom 2. Zarządzany (ang. Manager) – w firmie są podstawy zarządzania projektowego (zarządzanie wymaganiami, planowanie projektowe, monitoring i kontrola projektów, zarządzanie umowami z dostawcami, zapewnienie jakości projektów), Poziom 3. Zdefiniowany (ang. Defined) – w firmie są wystandaryzowane procesy zarządzania projektami informatycznymi (rozwój wymagań, definiowanie procesu, zarządzanie ryzykiem, integracja środowiska IT, zarzadzanie dostawcami), Poziom 4. Mierzony - Zarządzany ilościowo (Quantitative Management) – występuje zarządzanie ilościowe i mierzenie procesów zarządzania jakością projektów informatycznych; Poziom 5. Optymalizowany (ang. Optimizing) – w firmie zachodzi ciągłe usprawnianie procesów zarządzania projektami informatycznymi (wdrażanie innowacji, ciągła kontrola i ulepszanie).\n156 Metodyka PRINCE2 (Projects In a Controlled Environment)\nPRINCE2 jest standardem najpopularniejszym w Europie, gdzie obecnie po licznych uogólnieniach, stanowi alternatywę dla PMBOK. Metodyka ta została oparta na doświadczeniach uzyskanych przez kierowników projektów z krajów anglosaskich. Powstała w latach siedemdziesiątych XX w. pod nazwą PromptII (Project Resorce Organisation Management Planning Technique II). W 1989 r. po jej sprzedaży firmie LBMS, brytyjska agenda rządowa Central Computer and Telecommunications Agency (CCTA, obecnie będącej częścią Rządowego Biura Handlu - Office of Government Commerce) opublikowała nowy standard – PRINCE (PRojects IN Controlled Environments), określając go jako zbiór najlepszych praktyk zarządzania projektami informatycznymi Prace nad Prince2 zostały ukończone marcu 1996 kiedy opublikowaniem przez Biuro Wydawnictw Rządowych (The Stationery Office) podręcznika Zarządzanie projektami zakończonymi sukcesem przy pomocy Prince2 (Managing Successful Projects with Prince2).\n157 Metodyka PRINCE2 (Projects In a Controlled Environment)\nW 2009 roku została opublikowana najnowsza wersja tego standardu, w Wielkiej Brytanii jest on faktycznym standardem prowadzenia wszystkich rodzajów projektów. Standard ten jest wykorzystywany zarówno w sektorze prywatnym, jak i publicznym, tak aby zadowolić obecnych użytkowników i wciąż doskonalić w oparciu o zbierane na bieżąco doświadczenia. Został opracowany dla projektów informatycznych, ale jego elastyczność powoduje, że jest stosowany również w projektach z innych dziedzin. Opracowanie i rozwój tej metodyki spoczywa w rękach konsorcjum specjalistów od zarządzania oraz ponad 170 organizacji zarówno prywatnych i publicznych (Review Panel). Trudno jest ocenić zasięg użytkowników – biorąc pod uwagę liczbę zdających egzaminy na Prince 2 Foundation i Practicioner oceniano ich w 2009 r. na ponad 50 tys. osób.\n158 Rozwój metodyki podąża w kierunku\nmniejszej nakazowości i większej elastyczności, mniejszego oparcia na teorii, a większego na dobrych praktykach zarządzania, zasady używane w metodyce stają się mniej sztywne i powierzchowne, a bardziej zbliżone do rzeczywistości, dostosowanie metody do poszczególnych przypadków jest wyraźnie określone poprzez udostępnienie wytycznych dotyczące sposobu tej adaptacji, produkt jest zintegrowany z innymi programami firmy zapewniającymi zarządzanie udanymi produktami (Managing Successful Programes), zarzadzanie ryzykiem (Management of the Risk) itp., a połączenie z innymi dostępnymi użytkownikowi standardami i zasobami wiedzy jest jasno uwidocznione, rozwijane są i podkreślane miękkie aspekty zarzadzania projektami, metodyka staje się mniej biurokratyczna – bardziej istotne stają się w niej wymagane informacje i sposób podejmowania na ich podstawie decyzji, niż dokumenty i spotkania robocze\n159 Komponenty: W wersji z 2009 r. Prince2 składa się z następujących motywów (komponentów): uzasadnienie przedsięwzięcia, organizacja projektu, zapewnienie jakości, hierarchia planów, zarzadzanie ryzykiem, zarządzanie zmianą, kontrola postępów projektu.\n160 Komponenty: W uzasadnieniu przedsięwzięcia (business case) podaje się powody prowadzenia danego projektu, dopuszczalne warianty osiągnięcia celu projektu, spodziewane korzyści z jego wykonania, lista zagrożeń i barier w realizacji, zestawienie kosztów projektu, harmonogram oraz spodziewane efekty ekonomiczne jego wykonania (ocenę opłacalności). Ostatnie działanie jest iteracyjnie powtarzane, aby mieć pewność, że pomimo zmieniających się celów biznesowych (użytkownik uczy się w trakcie projektu i zmienia czasem wymagania) działanie zakończy się osiągnięciem zysku. W komponencie nazwanym – organizacja projektu - definiuje się zakres ról poszczególnych aktorów projektu (zarządzających i realizujących) oraz sugeruje (w wersji 2009 r.) zakres ich kompetencji i odpowiedzialności z niego wynikający. Obecnie dla Komitetu Sterującego oprócz obowiązków określa się również zachowania organizacyjne.\n161 Komponenty: Metodyka określa osiem podstawowych ról w projekcie::\nKomitet Sterujący (Project Board), Kierownik Projektu (Project Manager), Nadzór Projektu (Project Assurance), Kierownik Zespołu Specjalistycznego – rola opcjonalna (Team Manager), Wsparcie Projektu – rola opcjonalna (Project Support), Główny Użytkownik (Senior User), Główny Dostawca. Komitet Sterujący reprezentuje projekt na zewnątrz wobec Zarządu i składa się z osób, które prowadzą strategiczne sterowanie projektem i decydują za przydział zasobów do projektu (szczególnie finansowych) i nadzorują projekt. Przewodniczący Komitetu Sterującego - reprezentuje interesy wspólne dostawcy i odbiorcy produktu, rozstrzyga spory, przewodniczy posiedzeniom Komitetu oraz przewodzi projektowi. Personalnie odpowiada za jego prawidłowa realizację.\n162 Komponenty: Kierownik Projektu – jest odpowiedzialny za: planowanie i zarządzanie projektem, opracowanie i aktualizację planów, dostawy produktów, powierza wykonanie zadań, dokonuje odbioru, prowadzi dokumentację, rejestruje zadania projektowe, prowadzi aktualizację planów, prowadzi analizy zmian, przedkłada raporty Komitetowi Sterującemu, przewodzi i motywuje pracowników zaangażowanych w projekt. Kierownik Zespołu Specjalistycznego – odpowiada za opracowanie planów oraz sterowanie pracami, a także składa raporty kierownikowi projektu z osiągnięcia kamieni milowych (punktów kontrolnych) projektu. Członkowie Zespołu Specjalistycznego – powinni posiadać wiedzę i umiejętności konieczną do wykonania produktu, wytwarzać je wg założonych harmonogramów, odpowiadać za przygotowanie do kontroli jakości i zgodność jakości wytwarzanych produktów z jakością normatywną.\n163 Komponenty: Wsparcia projektu – udziela pomocy administracyjnej, nadzoruje standardy zarządzania projektem i jakością, prowadzi dokumentację, dokonuje rejestracji zagadnień projektowych, aktualizuje plany i analizuje skutki zmian, sporządza projekty dokumentów, protokoły z narad i przeglądów jakości. Główny użytkownik produktu – reprezentuje interesy przyszłych użytkowników projektu, nadaje priorytety kolejnym produktom, dokonuje oceny i akceptacji produktów, nadzoruje spełnienie zasad funkcjonalności i jakości produktów, odpowiada za efekty i spodziewane korzyści akceptowanych produktów oraz sprawuje cząstkowy nadzór nad częścią projektu, która go dotyczy. Główny dostawca produktu – reprezentuje interesy wykonawców produktu, przydziela i zwalnia niezbędne zasoby, odpowiada za integrację planowania i wykonawstwa specjalistycznych zadań projektowych oraz sprawuje specjalistyczny nadzór nad projektem i przyszłą eksploatacją i utrzymaniem produktu.\n164 Komponenty: W komponencie Hierarchia planów występują trzy poziomy planu: nadrzędny (plan projektu - Project Plan), cząstkowy (plan etapu – Stage Plan), szczegółowy (plan pracy zespołu – Team Plan). Oprócz tego występuje tzw. plan naprawczy (Exception Plan) w przypadku etapu, w którym pojawią się odchylenia przekraczające założone limity. Zarzadzanie ryzykiem – polega na eliminowaniu, minimalizacji lub utrzymywaniu ryzyka w założonych granicach. Składa się z takich elementów, jak: identyfikacja ryzyka – (rozpoznawanie i rejestracja) oraz zarządzanie ryzykiem (minimalizacja negatywnych wpływów). Zarejestrowane ryzyka są analizowane w trakcie postępu prac i zgodnie z planem redukcji ryzyka ograniczane. Zarzadzanie jakością polega na określeniu długookresowej polityki, która polega na dopilnowaniu (kontroli jakości), aby produkty spełniały założone wcześniej standardy kryteriów jakości założone (gwarancja jakości).\n165 Komponenty: Zarzadzanie zmianami w projekcie dotyczy drobnych modyfikacji, nienaruszających koncepcji biznesowych i architektonicznych. Obejmują: składanie wniosków o zmianę (request for change) – dotyczące zmiany w wymaganiach albo produkcie, rejestru odstępstw (off specification), sugestii zmian (suggestions), zapytań (queries) oraz definiowania problemów ogólnych związanych z modyfikacjami (general issue). Zarządzanie postępem – nie występowało w poprzednich wersjach, zastąpiło w zasadzie sterowanie projektem (Control) i zarządzanie konfiguracją (Configuration Management), wchłaniając ich funkcje. Z jednej stromy ma zapewnić prowadzenie projektu zgodnie z zakładanym harmonogramem i budżecie, z drugiej – kontrolować integrację tworzenia produktów. Zawiera elementy oceny etapowej i końcowej.\n166 Prince r. W metodzie Prince2 (2009 r.) wyróżniono siedem podstawowych procesów: Rozpoznanie i przygotowanie założeń projektu (rozruch - Starting up a project), Zarządzanie strategiczne (ogólne) projektem (Directing a project), Inicjalizacja (uszczegółowienie) projektu (Initiating a project), Kontrola wykonania etapu projektu (Controlling a stage), Zarządzanie zakresem etapu projektu (Managing a Stage Boundary), Zamykanie projektu (Closing a project). Istniejący w poprzedniej wersji proces Planowania projektu został zlikwidowany a jego podprocesy przydzielone i włączone do każdego z pozostałych procesów, z etapem ostatnim włącznie.\n167 Procesy Komponenty Techniki Rozpoznanie i przygotowanie założeń projektu (rozruch - Starting up a project), Zarządzanie strategiczne projektem (Directing a project), Inicjalizacja (uszczegółowienie) projektu (Initiating a project), Kontrola wykonania etapu projektu (Controlling a stage), Zarządzanie zakresem etapu projektu (Managing a Stage Boundary), Zamykanie projektu (Closing a project). Uzasadnienie przedsięwzięcia (Business Case), Organizacja projektu Organization), Zapewnienie jakości (Quality), Hierarchia planów (Plans), Zarzadzanie ryzykiem (Risk) Zarządzanie zmianą (Changes), Kontrola postępów projektu(Progress). Dwie podstawowe: Planowanie oparte na produktach (Product Based Planning) Kontrola jakości (Quality review) oraz szereg innych, odwołujących się do zasobów wiedzy projektowej np.: Zarządzanie zmianami (Changes Management) Zarządzanie przez wyjątki (Exception Management)\n168 Procesy w Prince 2 – 2009 r. Istniejący w poprzedniej wersji proces Planowania projektu został zlikwidowany a jego podprocesy przydzielone i włączone do każdego z pozostałych procesów, z etapem ostatnim włącznie. Rozpoznanie i przygotowanie założeń projektu (rozruch) polega na rozpoznaniu czy, w jaki sposób i w jakich warunkach finansowych projekt może być zrealizowany. Realizuje się go poczynając od zdefiniowania celów projektu i powołania zespołu kierowniczego, który te cele będzie osiągał, po uzasadnienie ekonomiczne i określenie wstępnych parametrów projektu (rozłożenie w czasie, budżet, elementy sterowania, uzgodnienia formalne). Zarządzanie strategiczne (ogólne) projektem – sprowadza się do koordynacji i podejmowania decyzji kluczowych dla rozwoju projektu przez Komitet Sterujący, w szczególności czy należy projekt kontynuować. Decyzje bieżące sa w kompetencjach Kierownika Projektu, za wyjątkiem (zarzadzanie poprzez wyjątki - management by exception) sytuacji kryzysowych - wyjścia poza zakres dopuszczalnej tolerancji odchyleń. W związku z czym rola Komitetu Sterującego głównie sprowadza się do wydawania zezwoleń na: inicjowanie projektu, wykonanie projektu lub etapu planu wyjątkowego, podejmowanie decyzji wynikających z zagrożeń i decyzji o zamknięciu projektu.\n169 Procesy w Prince 2 – 2009 r. Inicjalizacja (uszczegółowienie) projektu – składa się z dokładnego zaplanowania jego realizacji i wyszacowania zasobów (środki finansowe, zasoby ludzkie, wyposażenie) niezbędnych do osiągnięcia celu. Jest to dalsze uszczegółowienie założeń początkowych, które znajdzie się później w podstawowym dokumencie tego procesu tj. Dokumencie Inicjującym Projekt. Z tego wynikają podstawowe podprocesy tego procesu, takie jak np.: doprecyzowanie uzasadnienia projektu, planowanie projektu, planowanie jakości, zdefiniowanie elementów decyzyjnych, struktury informacyjnej i dokumentacji projektowej oraz stworzenie Dokumentu Inicjującego Projekt. W procesie Kontroli wykonania etapu projektu realizowane jest bieżące zarządzanie projektem przez Kierownika Projektu. Ilość etapów zależy od branży, w której projekt jest realizowany, zakresu podjętych prac, skali przedsięwzięcia, poziomu i wartości ryzyka oraz ilości i znaczenia tzw. kamieni milowych – najważniejszych punktów decyzyjnych, w których są podejmowane decyzje o opłacalności kontynuacji projektu. Po wyrażeniu zgody na wykonanie grupy zadań, odbywa się okresowa ocena postępów prac na podstawie przeglądu stanu danego etapu i jego zgodności z analizą zarejestrowanych zagadnień projektowych. W przypadkach udokumentowanych i uzasadnionych odchyleń od zakładanych wartości podejmowanie decyzji o korekcie, zmianach, modyfikacjach bieżących, tworzenie raportów o istotnych wydarzeniach i odbieranie wykonanej grupy zadań.\n170 Procesy w Prince 2 – 2009 r. Zarządzanie zakresem etapu projektu – każdy z etapów metodyki musi być zakończony i przyjęty przez Komitet Sterujący, przed przejściem do etapu następnego. Obejmuje opracowanie planu bieżącego zakresu etapu, jego uaktualnianie wraz z potencjalną korektą uzasadnienia biznesowego oraz podejmowanego ryzyka, opracowanie – w razie potrzeby planu naprawczego oraz tworzenie raportu o zakończeniu etapu. Zamykanie projektu – polega na sprawdzeniu czy wszystkie zamówione produkty w postacie zgodnej z normatywami zostały wykonane i dostarczone użytkownikowi i przez niego zaakceptowane. Wg metodyki Prince2 powinno się to odbywać w sposób uporządkowany i kontrolowany. Zbierane i rejestrowane są doświadczenia z projektu. Po jego zakończeniu przeprowadzany jest przegląd oceniający projekt i wyciągane wnioski na przyszłość umieszczane wraz z analizą z oceny w raporcie o dokonaniach projektu.\n171 Procesy w Prince 2 – 2009 r. Planowanie jest procesem trwającym przez cały cykl życia projektu, co sprawia że jego podprocesy występują we wszystkich pozostałych procesach. Obejmuje więc przede wszystkim takie kroki jak: przeprowadzenie identyfikacji ustalenie kolejności wykonania czynności w celu osiągnięcia odpowiednich własności produktu (sekwencjonowanie), zdefiniowanie kolejnych zdarzeń w projekcie i ich wzajemnych relacji, szacunki pracochłonności, opracowanie harmonogramu działań wraz z oceną ryzyka za pomocą odpowiednich narzędzi.\n172 Zalety metodyki Prince2\nzawiera uogólnioną, usystematyzowaną, częściowo sformalizowaną ekspercką wiedzę z zakresu zarzadzania projektami, stanowi dobre medium komunikacji - jest metodyką powszechnie znaną, co ułatwia porozumiewanie się pomiędzy wszystkimi interesariuszami projektu i zespołami projektowymi, ponadto organizuje dobrze działające kanały łączności pomiędzy wszystkimi interesariuszami projektu, występuje w niej możliwość lepszego kontrolowania zużycia zasobów przez projektanta i odbiorcę projektu, umożliwiona jest poprawna strukturalizacja zadań od inicjacji po zakończenie, możliwy jest regularny monitoring postępu w pracach i automatyzacja kontroli odchyleń od ustalonego planu,\n173 Zalety metodyki Prince2\nrozłożenie punktów decyzyjnych w projekcie jest mniej sformalizowane niż w innych metodykach, zapewnia zaangażowanie Komitetu Sterującego poprzez odciążenie od zadań bieżących i daje Kierownikowi Projektu dzięki zasadzie zarzadzanie przez wyjątki możliwość działania bez zbędnych ingerencji Komitetu Sterującego, przy jego poparciu w sytuacjach nadzwyczajnych, dzięki jej stosowaniu występuje wysoka powtarzalność i standaryzacja, zwłaszcza projektów uniwersalnych, o wspólnej terminologii, podejściu i dokumentacji, co z jednej strony umożliwia powtórne zastosowanie w podobnych przypadkach, a z drugiej zapewnia możliwość doskonalenia kompetencji, standaryzacja jest wzmacniana przez dostarczanie kompletnych wzorców i wręcz szablonów dokumentacji o pełnej spójności i porównywalności, pomimo standaryzacji zawiera mechanizmy ograniczonej adaptacyjności do specyficznych wymogów organizacji lub projektu, opiera się na najlepszych praktykach zarządzania (w granicach rozsądku), jest powszechnie dostępna, co ogranicza wkład własny w tworzony projekt, nie wymaga opłat autorskich za stosowanie w projektach.\n174 Wady metodyki Prince 2 wyrywkowość stosowania metody, bez zwracania uwagi na podstawowe zasady w niej występujące powszechna dostępność – co oprócz korzyści przynosi zaniechanie własnych wysiłków w celu doskonalenia metod zarządzania projektami, praktyka nadmiernego dokumentowania w procesach kontroli sposobu realizacji projektu (od której odchodzi się już od wersji z 2009 r. począwszy), występująca niekiedy nadmierna komunikacja (regularna wymiana informacji pomiędzy interesariuszami) w projekcie, gdzie spotkania robocze są tak częste, że przeszkadzają tokowi prowadzonych prac, brak bezpośrednio definiowanej analizy wymagań użytkownika, co z jednej strony przyspiesza prace projektowe, ale z drugiej może prowadzić do przyjęcia fałszywych, bądź niepełnych założeń, nadmierna skala pracochłonności, spowodowana zbyt literalnym przyjęciem zasad metodyki Prince2, przyjęta dla małych projektów może spowodować brak opłacalności jej zastosowania.\n175 Metodyka ITIL (Information Technology Infrastructure Library)\nITIL (Information Technology Infrastructure Library) należy traktować jako modelową bibliotekę modeli będących najlepszymi praktykami w zakresie zarzadzania usługami informatycznymi (IT Service Management), którą stosuje się jako pomoc w ich wdrażaniu. W skład tej biblioteki wchodzi określona mapa procesów oraz ich dodatkowych charakterystyk (pojęć, relacji, ról organizacyjnych, mierników) zawierających wiedze ekspercką na temat całego cyklu życia każdej wyspecyfikowanej usługi informatycznej z perspektywy klienta oraz firmy informatycznej. Jest to de facto zbiór uogólnionych zaleceń i rekomendacji branży informatycznej, określających sposób efektywnego i skutecznego oferowania i wdrażania usług informatycznych.\n176 Jest to metodyka: Opisująca jedynie najlepsze praktyki zarządzania usługami IT, na podstawie których dopiero opracowuje się specyficzne dla danej firmy procedury - nie wdraża się natomiast gotowych instrukcji przygotowanych dla każdego typu organizacji, Nie jest to bowiem narzędzie, a biblioteka procesów opisująca kompleksowo całą organizację IT, zawierająca ekspercką wiedzę na temat zarządzania usługami IT, Jest więc to zestaw porad, wytycznych i wskazówek jak unikać podstawowych błędów w zarządzaniu usługami IT i jakie w związku z tym wprowadzać kompleksowe rozwiązania sprawdzone w innych organizacjach, pamiętając przy tym o silnych relacjach między poszczególnymi obszarami występującymi w ITIL.\n177 Metodyka ITIL (Information Technology Infrastructure Library\nMetodyka ITIL, w wersji trzeciej, składa się z pięciu zintegrowanych tematycznie pozycji analizujących po kolei wszystkie etapy jej cyklu życia. Zgodnie z tym założeniem podręczniki zatytułowane są w sposób następujący: Strategia usług (Service Strategy), Projektowanie i przeprojektowywanie usług (Service Design), Wdrażanie usług i zarządzanie zmianą (Service Transition), Eksploatacja usług (Service Operation), Nieustanne doskonalenie usług (Continual Service Improvement)\n178 1. Strategia usług Do procesów strategii usług zaliczamy:\nzarządzanie portfelem usług - proces odpowiedzialny za określenie potrzeb użytkownika i stworzenie dla niego oferty usług IT, uwzględniające jego korzyści. Portfel usług składa się z takich elementów, jak: planowanie dostarczanych usług, katalog usług oraz rejestru wycofanych usług (zarchiwizowane w bazie wiedzy, specyficzne, zakończone już usługi, udostępniane w podobnych przypadkach). Zarządzanie portfelem usług zawiera cztery etapy: Definiowania (lista usług, studium przypadków, weryfikacja danych w portfelu), Analizy (proponowane wartości, uzgadniania, negocjowanie i ustalanie priorytetów, bilansowanie podaży i popytu), Zatwierdzanie (wyznaczanie i autoryzacja uzgodnionego portfela usług), Projektowanie (przekazanie decyzji i przydział zasobów do realizacji portfela usług IT).\n179 1. Strategia usług zarządzanie finansami – dostarczanie informacji o wartościach usług IT oraz prognozach ich wielkości (planowanie budżetu dostawcy usług IT, księgowanie kosztów dostarczenia usług, naliczanie opłat za usługi IT), zarządzanie popytem – identyfikacja wzorców zachowań użytkowników oraz polityki zróżnicowania opłat za pożądane zachowania klienta – tak aby przynosiły największe korzyści dla obu stron (użytkownika oraz firmy dostarczającej usługi TI). Klient nie będzie chciał korzystać z oferty, z której nie ma korzyści.\n180 2. Projektowanie i przeprojektowywanie usług (service design)\nProjektowanie i przeprojektowywanie usług (service design) - na podstawie wymagań biznesowych oraz wytycznych z poprzedniej fazy odbywa się projektowanie nowych lub zmianę już istniejących usług, które będą wdrażane do eksploatacji. Zasadniczymi celami tego etapu są: projektowanie usług i obsługujących je procesów, projektowanie zasad bezpieczeństwa, projektowanie miar oceny (efektywności, użyteczności itd.), Identyfikację ryzyka projektu, tworzenie i/lub aktualizacja dokumentacji, projektowanie udoskonalania jakości usług IT. Do procesów występujących w etapie projektowania i przeprojektowywania usług zaliczamy: Proces udostępniania usług do wykonania - realizowany zgodnie z katalogiem usług dzielącym się na: katalog biznesowy (zawierający informacje o usługach IT przekazywane i widoczne dla klienta) mapujących (nakładających) usługi IT na procesy biznesowe oraz katalog techniczny (zawierający informacje o usługach dostarczanych klientowi, ale dla niego niewidocznych), mapujących usługi IT na infrastrukturę teleinformatyczną,\n181 2. Projektowanie i przeprojektowywanie usług (service design)\n182 2. Projektowanie i przeprojektowywanie usług (service design)\nproces zarządzanie dostawcami - czynności zmierzające do zapewnienia uzgodnionego wypełnienia zobowiązań przez dostawców, proces zarządzanie ciągłością usług IT - zarządzanie ryzykiem, narażającym na zakłócenie wykonania danej usługi. Doprowadza do zapewnienia klienta, że dostawca zawsze jest w stanie dostarczyć usługę na poziomie akceptowalnym. Cykl życia tego procesu składa się z pięciu etapów: inicjacji (ustalenia polityki zapewnienia ciągłości, zdefiniowania zakresu, zainicjowania uruchomienia projektu), analizy wymagań i ustalenia strategii ciągłości działań (analiza wpływu na biznes, ocena ryzyka, opracowanie strategii ciągłości usługi IT), planowania ciągłości i wdrożenia (projektowania planów ciągłości usługi IT, projektowania planów IT, planowania organizacji, opracowania strategii testowania), uruchomienia i eksploatacji (szkolenia, podnoszenia świadomości użytkownika, przeglądu i audytu, testowania, zarządzania zmianami).\n183 3. Etap wdrażania usług i zarządzania zmianą (Service Transition)\nEtap wdrażania usług i zarządzania zmianą (Service Transition) – polega na zarządzaniu i koordynacji wszystkich elementów potrzebnych do zbudowania, testowania i wdrożenia usługi u klienta, zgodnie z ustalonymi warunkami. Składa się z takich elementów, jak: zarządzanie zmianą - proces koordynowania modyfikacji w trakcie wdrażania usług IT z ustalonymi celami i harmonogramem. Obejmuje on takie czynności, jak: rejestracja zmian, ocena ich istotności, wyznaczanie priorytetów realizacji, planowanie zmian, testowanie zmian, wdrażanie zmian i prowadzenie dokumentacji bieżącej tych czynności. W modelu ITIL wyróżnia się zmiany normalne, standardowe (wcześniej przewidziane, o niskim stopniu ryzyka, łatwe do realizacji, niskie koszty) oraz awaryjne (nagły, nieprzewidywalny i istotny błąd systemu, szybki tryb wprowadzenia poprawek), zarządzanie komponentami usług i konfiguracją - proces dostarczenie szczegółowych informacji na temat zasobów oraz zapewnienia kontroli nad zasobami i infrastrukturą organizacji. W trakcie procesu wykonywana jest sekwencja czynności, takich jak: zarządzanie i planowanie elementów usług i konfiguracji, jej identyfikację i kontrolę, obsługę bieżącego stanu i dostarczanie na ten temat raportów, weryfikacje oraz audyt komponentów i konfiguracji.\n184 3. Etap wdrażania usług i zarządzania zmianą (Service Transition)\nzarządzanie wiedzą - proces polegający na: rejestracji, analizie wykorzystania oraz dystrybucji informacji i wiedzy w organizacji. Podstawowym celem jest uniknięcie powtarzalności zdobywania wiedzy organizacyjnej, planowanie i wspieranie wdrażania usług i zarządzania zmianą - proces odpowiedzialny za zaplanowanie wszystkich procesów wdrażania usług oraz koordynację zasobów, dla ich realizacji. Głównymi celami tego procesu są kontrola wraz z identyfikacją i zarzadzaniem ryzykiem wystąpienia błędu wykonania usługi, a także planowanie i koordynacja zasobów realizacyjnych. ocena - proces polegający na ocenie zmodyfikowanych lub nowowprowadzonych usług IT, wg wcześniej określonych miar i kryteriów, co uzasadnia wprowadzenie zmiany i jest weryfikacją poprawności podjętej w tym zakresie decyzji, zarządzenie wersjami i wdrożeniami – proces kontroli i planowania udostepnienia wersji testowego i eksploatacyjnej oraz przekazania nowego sprzętu, oprogramowania itp. niezbędnej do realizacji usługi IT, weryfikacja i testowanie usług - proces który ma zapewnić poprawność usługi i jej zgodność z podpisanymi zobowiązaniami.\n185 4. Eksploatacja usług (Service Operation)\nEksploatacja usług (Service Operation) – faza cyklu życia polegająca na zarządzaniu systemami i infrastrukturą informatyczną, w celu dostarczenia usług IT użytkownikom oraz klientom na poziomie uprzednio uzgodnionym. Eksploatacja usług odbywa się poprzez realizację pięciu procesów: zarządzania incydentami - proces przywracania poprawnego działania usługi oraz usunięcie negatywnych skutków, jakie mogły się w międzyczasie pojawić, realizacja (spełnienie) wniosków – proces wspomagający użytkownika w dostarczaniu standardowych usług i skarg na ich niewypełnienie, zarządzanie uprawnieniami dostępu – proces przydzielania użytkownikom praw dostępu i uprawnień do wykonywania funkcji w ramach przydzielonych im usług IT, zarządzanie zdarzeniami - główny proces w tej fazie polegający na wykrywaniu, reakcji na zdarzenia, które występują w trakcie cyklu życia danej usługi, zarządzanie problemami - proces zapobiegający pojawianiu się kłopotów, a w momencie ich pojawienia powodujący minimalizację skutków. Składa się z dwóch części pasywnej (identyfikacja i specyfikacja) i aktywnej (doskonalenie tak aby zidentyfikowane problemy więcej nie wystąpiły).\n186 4. Eksploatacja usług (Service Operation)\nProcesy występujące w tej fazie są realizowane w trakcie czterech podstawowych funkcji: pulpit usług – główne medium komunikacji do zgłaszania nieprawidłowości w działaniu systemu informatycznego oraz wniosków o udostępnienie określonej usługi, zarządzanie techniczne – wspieranie technicznych usług zarządzania systemem (main frame, serwerów, sieci, Internetu, pamięci masowej, baz danych, usług katalogowych, desktopu itd.), zarządzanie aplikacjami – odpowiada prawidłowe działanie różnych rodzajów aplikacji oraz identyfikuje potrzeby podczas wdrażania aplikacji, zarządzanie eksploatacją IT - zarządzanie infrastruktura informatyczną, kontrola eksploatacji (obsługa konsoli, przetwarzanie wsadowe, archiwizacja, wydruki) oraz zarządzanie wyposażeniem (centra danych, zapasowe centra danych, konsolidacja itp.).\n187 5. Nieustanne doskonalenie usług (Continual Service Improvement)\nNieustanne doskonalenie usług (Continual Service Improvement) – jest to faza, która może wystąpić w każdym momencie cyklu życia realizowanych usług, odpowiadająca za podnoszenie jakości usług oraz związanych nią procesów, które są następujące: mierzenie jakości danej usługi IT – ustalenie mierników i prawidłowego sposobu mierzenia dla poszczególnych komponentów usługi IT, opracowywanie raportowanie jakości dotyczących poszczególnych usług – publikacja wyników analiz mierzenia jakości usług, siedmio-stopniowy proces doskonalenia jakości usług – składający się z identyfikacji strategii ulepszania (wizja, wymagania i ograniczenia, cele taktyczne i operacyjne wraz ze strategią ich osiągnięcia), identyfikacja ocenianych komponentów, zebranie danych dotyczących oceny (o wykonawcy, sposobie wykonania, terminarzu, wyznaczenie kryteriów spójności danych, wyznaczenie celów operacyjnych oraz miar jakości usług), przetwarzanie danych (ustalenie częstotliwości, formatu, narzędzi i systemów oraz dokładności obliczeń), analiza wyników (wynikające z niej trendy, nowe cele i kierunki działania, ewentualne wymagane działania usprawniające), wykorzystanie oceny (podsumowanie wyników i plan działań) oraz wdrożenie działań doskonalących.\n188 Zalety ITIL Zalety metodyki ITIL\nPodstawowe zalety biblioteki polegają na: możliwości wykorzystania zasobów zgromadzonej w niej wiedzy o prawidłowej realizacji procesów realizacji usług IT w innych organizacjach, minimalizacji kosztów wdrożenia - organizacja nie ponosi wysokich kosztów związanych z wdrożeniem tej metodyki, poza kosztami szkoleń dotyczących możliwości jej wykorzystania, polepszeniu komunikacja wzajemnej – używanie wspólnego, w pewnym sensie znormalizowanego języka oraz praca w dziale IT według wspólnych reguł, polepszenie relacji z klientem - skupienie uwagi na korzyściach ekonomicznych klienta już w początkowych etapach stosowania metodyki, zarządzanie jakością - ciągłe doskonalenie jakości organizacji oraz wykonywanych w niej usług informatycznych\n189 Wady ITIL Wady metodyki ITIL\nnajwiększą wadą według użytkowników jest fakt, że metodyka ta jest tym czym jest a więc biblioteką – listą czynności do wykonania w określonych przypadkach, a nie daje wskazówek co do tego, jak prawidłowo stosować najlepsze praktyki, które są w niej opisane. Każda organizacja musi więc stosując zasady ITIL opracować sobie własne procesy wraz z ich obsługą, ITIL jest więc tyko schematem postepowania, ramą, która następnie należy wypełnić specyficzną dla danej organizacji treścią – nie każda organizacja ma pracowników, którzy są w stanie sami to zrobić. Zatrudniają więc do konsultacji tych samych ludzi, którzy tworzyli zasady ITIL – tak więc redukcja kosztów związana z zastosowanie ITIL jest tylko pozorna, stosowanie ITIL wymaga przeprowadzenia dedykowanych szkoleń, za które trzeba płacić, dostępne podręczniki opisujące metodykę są relatywnie drogie z perspektywy zastosowań niekomercyjnych.\n190 Metodyka The Open Group Architecture Framework (TOGAF)\nProjektowaniem, utrzymywaniem i wprowadzaniem zmian do architektury IT zajmuje się metodyka The Open Group Architecture Framework (TOGAF) Version 9. W metodyce TOGAF występuje otwarta ramowa struktura implementacji – w zasadzie jest to szczegółowo opisany zestaw narzędzi wspomagających opracowanie architektury korporacyjnej. Może być używany każdej organizacji pragnących rozwijać architekturę korporacyjną. TOGAF występuje w postaci ram architektonicznych (lecz nie jest to architektura), niezależnych od dostawców, powstałych na drodze konsensusu wypracowanego w ramach Open Grup, zawierają rygorystyczną metodę tworzenia architektury (Architecture Development Method - ADM), która pozwala na przejście od architektury generycznej do architektury dedykowanej konkretnej organizacji, składa się z zestawu usług, standardów, pojęć projektowych, komponentów i konfiguracji\n191 Metodyka The Open Group Architecture Framework (TOGAF)\nTOGAF został opracowany i jest rozwijany przez członków tzw. Open Group, Pierwsza wersja metodyki TOGAF powstała w 1995 roku w oparciu o zasady Technical Architecture Framework for Information Management (TAFIM), opracowane przez amerykański Departament Obrony USA. Departament Obrony udzielił Open Group pozwolenia na przejęcie metodyki i jej rozwój w postaci kolejnych wersji już pod nazwą TOGAF.\n192 Fazy budowy architektury korporacyjnej (w tym IT)\nfaza wstępna – określenie ustalenia zakresu działania organizacji dla którego będzie realizowane przedsięwzięcie związane ze zwiększeniem innowacyjności (w tym wdrożenie rozwiązań IT) oraz identyfikowany jest sponsor tych prac, wizja architektury – utworzenie wizji organizacji, która prezentować będzie zakładany poziom dojrzałości w obszarze innowacyjności (w tym IT). Następuje identyfikacja interesariuszy związanych z zapewnieniem realizacji celów i określenie ich potrzeb. Rozpoznawane są główne czynniki ryzyka dla planowanego przedsięwzięcia, a także ustalany jest plan komunikacji dla tego przedsięwzięcia, architektura biznesowa - opisuje strukturę przedsiębiorstwa w odniesieniu do jego zadań biznesowych, struktury zarządczej, procesów biznesowych i informacji biznesowej. Jest to wprowadzenie do ustalania architektury korporacyjnej,\n193 Charakterystyka metody TOGAF\narchitektura danych (część architektury systemów informatycznych) - przedstawia strukturę i charakterystykę danych zaangażowanych do wsparcia architektury biznesowej (zadań biznesowych, procesów biznesowych itp.) oraz wskazuje systemy informatyczne używane do przetwarzania tych danych, architektura aplikacji (część architektury systemów informatycznych) - ukazuje strukturę systemów informatycznych, ich wzajemne relacje i lokalizację w otoczeniu, a także informuje, w jaki sposób uczestniczą one w zadaniach opisanych w ramach architektury biznesowej i architektury danych, architektura technologii - charakteryzuje technologie użyte do wsparcia elementów architektury biznesowej i architektury danych. Określa też strukturę komponentów technologicznych i ich wzajemne relacje,\n194 Charakterystyka metody TOGAF\nrozwiązania IT – prezentują sposób przejścia od stanu obecnego architektury do jej stanu docelowego; zawierają opisy nanoszące opis docelowy na opis stanu obecnego (architekturę przejściową), pozwalając określić plan działań, plany migracji przedstawiają szczegółowy plan wdrożenia nowych systemów z uwzględnieniem scenariuszy migracji danych, zgodnie z rozwiązaniami określonymi na poprzednim poziomie, zarządzanie wdrożeniem - opisuje sposób wdrożenia nowego system IT do architektury przedsiębiorstwa, uwzględniając powiązania z innymi komponentami architektury, zarządzanie zmianą architektury IT - ma na celu utrzymywanie spójnego, aktualnego i zgodnego z przyjętym standardem opisu architektury podczas zmian dokonywanych na którymkolwiek z jej poziomów\n195 Charakterystyka architektury danych w TOGAF\nkonceptualny model danych (Conceptual Data Model - CDM) - jest to rodzaj słownika porządkującego koncepcję architektoniczną organizacji. Znaleźć w nim można szeroki zakres kategorii danych (np. rejestr klientów, dostawców, inwentaryzację zakupów itp.) użytkowanych w organizacji, stanowiących główne obiekty porządkujące informacje zbierane przez firmę. Model ten zawiera również opis relacji pomiędzy danymi określony z perspektywy biznesowej, a więc niezależnie od sposobu, w jaki te dane są kategoryzowane przez przetwarzające je systemy informatyczne, Logiczny model danych (Logical Data Model) - to słownik zapisu danych. Jest kolejnym etapem uszczegółowienia w stosunku do wyższego poziomu. Przedstawia dane opisane na poziomie modelu konceptualnego w postaci konkretnych atrybutów danych, identyfikuje format tego zapisu i pokazuje powiązania pomiędzy nimi (np. nazwa, adres, rodzaj, powiązanie itp.). Po to by uzyskać ustrukturyzowany zapis model ten normalizuje atrybuty danych w zakresie całej architektury danych. Proces normalizacji polega na takim zorganizowaniu i opisaniu atrybutów danych, które zapewniają spójność i jednorodność tego zapisu, a także eliminują w opisie duplikaty atrybutów zawierających tę samą wartość informacyjną, Fizyczny model danych (Physical Data Model) - jest specyficznym słownikiem, tłumaczącym atrybuty modelu logicznego na ich techniczne odpowiedniki, które mogą zostać użyte w systemach zarządzania danymi.\n196 Korzyści z zastosowania metodyki TOGAF\nKorzyści z zastosowania metodyki TOGAF, widoczne w rachunku zysków i strat organizacji są przedstawiane w sposób następujący: bardziej efektywne działanie firmy wyrażające się: niższymi kosztami działalności gospodarczej, elastycznością i adaptacyjnością organizacji, udostepnienie korzyści całej organizacji, obniżenie kosztów zarządzania zmianami, zwiększenie elastyczności zatrudnienia, poprawa wydajności pracy, bardziej wydajne zastosowanie IT w organizacji: zmniejszenie kosztów oprogramowania, wsparcia, utrzymania systemów informatycznych, zwiększona mobilność aplikacji, poprawa interoperacyjności i łatwiejsze zarządzanie systemem i siecią, poprawa zdolności do rozwiązania najważniejszych problemów w skali całego przedsiębiorstwa, takich jak np. bezpieczeństwo systemów informatycznych, łatwiejsza wymiana oprogramowania na nowsze wersje i wprowadzanie modyfikacji,\n197 Korzyści z zastosowania metodyki TOGAF\nzwiększenie zysków z bieżących inwestycji, zmniejszenie ryzyka dla przyszłych: redukcja złożoność biznesu i IT, maksymalizacja zwrotu z inwestycji w istniejącej działalności i infrastruktury IT, zwiększenie elastyczności wyboru pomiędzy outsourcingiem, a możliwością zakupu rozwiązań IT, zmniejszenie ryzyka inwestowania, szybsze, prostsze i tańsze, zamówienia publiczne: decyzji o zakupie są prostsze, ponieważ informacja o zamówieniach jest łatwo dostępna, proces zamówień jest szybszy – występuje maksymalizacja prędkości oraz elastyczności tworzenia i składania zamówienia bez utraty spójności architektonicznej, zdolność do tworzenia otwartych systemów wielu dostawców (multi-vendor), możliwość do zwiększenia potencjału gospodarczego organizacji.\n198 Metodyka Six-Sigma Sześć Sigma (ang. Six Sigma) – jest to metoda zarządzania projektami skupiająca się w zasadzie na zarządzaniu jakością produktów i/lub usług, poprzez minimalizację ilości niedociągnięć i w rezultacie usprawnieniu działania organizacji. W chwili obecnej, jak wszystkie tego typu metodyki obrasta w kwestie ideologiczne i filozoficzne. Zasadniczym, pierwotnym celem metody jest zwiększenie jakości do poziomu 99,99966% zgodności z założonymi, oczekiwanymi standardami. Odpowiada to średniej ilości 3,4 usterek na milion (liczba defektów na milion szans ich zaistnienia - DPMO - Defect per Million Opportunities), co stanowi sześć odchyleń standardowych (stąd nazwa - 6 sigma, sigma litera najczęściej w statystyce używana dla określenia właśnie odchylenia standardowego) od rozkładu normalnego wynikającego z obserwacji danego zjawiska\n199 Metodyka Six-Sigma Poziom jeden sigma – oznacza około 700 tys. defektów na milion i dla firmy oznacza katastrofę. Poziom trzy sigma jeszcze trzydzieści lat temu był uznawany za wystarczający standard jakości. Sześć sigma - to doprowadzenie jakości niemal do perfekcji. Czyli - jak z tego wynika - celem Six Sigma jest zapewnienie niemal stu procentowej zgodności zaplanowanych rezultatów z rzeczywistymi wynikami. Z drugiej strony wiadomo, że większość zjawisk gospodarczych nie chce mieć rozkładu normalnego. Tak więc, ta nadwyżka nad poziomem trzy sigma ma widocznie rekompensować zaburzenia założeń teoretycznych metody. Od strony filozoficznej Six Sigma stawia na zarządzanie zmianą - …lepiej jest zarządzać problemem niż go potem eliminować…. Czyli – na wykrywanie błędów i przyczyn ich powstania – i jak najpełniejsze – ich eliminowanie zanim jeszcze się pojawią. Oczywiście – aby tym problemem zarządzać trzeba dysponować dużą ilością mierzalnych, a najlepiej powtarzalnych obserwacji. Stąd drugie poważne założenie metodyki – to mierzalność zjawisk, które są brane pod uwagę przy podejmowaniu decyzji.\n200 Metodyka Six-Sigma Stworzona w połowie lat osiemdziesiątych XX w. w firmie Motorola przez B. Gavina po odkryciu przez niego zależności pomiędzy ilością błędów w procesie produkcji a całkowitym kosztem wytworzenia produktów i usług. Identyfikacja defektów i eliminacja ich przyczyn spowodowała znaczące oszczędności, spowodowanych zmniejszeniem kosztów wykrywania i usuwania usterek oraz potencjalnych, związanych z tym reklamacji. Od tego czasu doskonalona, stosowana nie tylko do usprawniania procesów produkcji (Motorola, Honeywell, Alstom, 3M, Microsoft, General Electrics), ale również np. do wspomagania administracji, finansów, ubezpieczeń itp.. Powszechnie znana i uznana, daje najwyższy i najszybszy zwrot z inwestycji. …Motorola, lider konsorcjum organizacji, które rozwinęły podejście Sześć Sigma, relacjonuje oszczędności w wysokości 11 mld dolarów, uzyskane w ciągu dwunastu lat od pierwszych implementacji Sześć Sigma w jej zakładach na podstawie… przykład … General Electrics, który dzięki implementacji Six Sigma zaoszczędził 750 milionów dolarów w 1995 roku. …\n201 Metodyka Six-Sigma W metodyce Six Sigma występuje sześć podstawowych zasad: skupienie się na kliencie i jego wymaganiach – rozpoznanie zidentyfikowanych i niezidentyfikowanych potrzeb klienta i ich mierniki, zarządzanie oparte o informacje – określenie wskaźników poziomu działania firmy, kluczowych kryteriów oceny i optymalizacja rezultatów, zarządzanie procesami i ich ulepszanie, aktywne zarządzanie – wykonywanie czynności najlepiej zanim się coś wydarzy, antycypowalność zdarzeń i ich skutków, nieograniczona współpraca – zrozumienie potrzeb końcowych użytkowników i opanowanie przepływów dokumentacji (workflow) w całej organizacji, celem jest doskonalenie procesów, przy tolerancji dla niepowodzeń – ciągłe samodoskonalenie oraz uznanie dla konieczności popełniania błędów w procesie zarządzania\n202 Metodyka Six-Sigma Podstawą jej stosowania jest procedura metodyczna , nazwana od pierwszych liter poszczególnych jej faz DMAIC: definiuj (Define) – w etapie tym następuje inicjacja i identyfikacja, poznanie i opisanie procesów oraz ich słabych stron, określenie celów, ograniczeń oraz obszarów występowania procesów, identyfikacja cech krytycznych i zadań do rozwiązania (czyli określenie problemów i procesów, które są przyczyną defektu i skoncentrować na tych, których poprawa przyniesie największą korzyść). Technikami analitycznymi na tym etapie mogą być diagramy przyczynowo-skutkowe, metoda ABC i kalkulator Six Sigma, mierz, wymiaruj (Measure) – to sposób poznania w sposób jasny, precyzyjny i dokładny obiektywnej prawdy o obiekcie, a wyniki pomiaru powinny być jasno i jednoznacznie interpretowane. Polega na zebraniu informacji o aktualnym stanie procesu, dla ustalenia poziomu odniesienia i skali problemu, czyli zbioru cech procesu i działań nieakceptowalnych dla klientów (liczba błędów i szans na ich popełnienie), określeniu metod pomiaru wymagań klientów oraz przeprowadzeniu szczegółowych pomiarów (ocena potrzeb klienta lub rynku, porównanie z konkurencją itp.). Techniki analiztyczne używane na tym etapie to: statystyki opisowe, wykres Ishikawy, wykresy z szeregów czasowych itp.\n203 Metodyka Six-Sigma analizuj (Analyse) – w etapie tym przeprowadzana jest analiza danych w celu zidentyfikowania przyczyn defektów oraz sposobu ich uniknięcia, wskazanie krytycznych powodów problemów i ich wpływu na proces, analiza i ocena pomiarów, specyfikacja odchyleń i metod ich eliminacji (badanie różnych opcji procesu). Obliczamy ile zyskamy na poprawie poszczególnych procesów przez eliminacje ewentualnych błędów. Korzysta się tu z diagramów przyczynowo-skutkowych, testów dla prób zależnych i niezależnych, analizą przekrojową, poprawiaj, usprawniaj, udoskonalaj (Improve) – w etapie tym dokonywane jest wskazanie procesów do poprawienia i wprowadzenie rozwiązań usuwających wyspecyfikowane problemy, poszukiwanie nowych rozwiązań, minimalizacja odchyleń, kreowanie zmian i ich wdrażanie lub projektowanie procesu – tak aby spełniał oczekiwania klienta, ingerencja w tok proces, po to by obniżyć poziom występowania błędu, poprzez zmniejszenie odchyleń. Elementem tego etapu jest planowanie, wykonanie i analiza wyników doświadczeń dotyczących kluczowych kategorii procesu. Technikami analitycznymi są tu – karty kontrolne, analiza Pareto, kalkulator Six Sigma, analiza przekrojowa, wykresy przekrojowe,\n204 Metodyka Six-Sigma kontroluj, sprawdzaj (Control) – oznacza tu zakończenie, weryfikację skuteczności podjętych działań i – w wyniku tego wprowadzanie nowych postaci procesów, identyfikację i monitoring wyników, w celu uzyskania wysokiego poziomu jakości poprzez określenie zakresu zadań oraz ról i odpowiedzialności za jakość właścicieli procesów lub testowanie – sprawdzające czy proces spełnia wymagania klienta. Najczęstszą techniką działania jest tu stosowanie kart kontrolnych.\n205 Metodyka Six-Sigma W tradycyjnej metodyce zarządzania projektem występuje podział na etapy rozpoczęcia (inicjacji), planowania (definiowanie i analiza), realizacji, kontroli oraz zamknięcia analogiczne do etapów metody Six Sigma. Poszczególne z nich są wspomagane, specjalnie stworzonymi i przystosowanymi do tej metody narzędziami dodatkowymi: ukierunkowanymi na klienta w celu rozpoznania jego potrzeb (VOD - Voice of the Customer) – określenie potrzeb klienta i jego preferencji oraz śledzenie ich zmian; prowadzenie monitoringu sytuacji, ukierunkowanymi na jakość przekazu - konwertującymi wymagań klienta na język zrozumiały dla projektanta systemu oraz – zwrotnie - projektanta i programisty na język użytkownika i rynku (QFD – Quality Function Deployment), definiującymi procesy i role w projekcie (diagram SIPOC (skrót od Supplier, Input-Process-Output, Customer)) - rozpoznanie i długotrwała analiza procesów, miejsca i roli wykonawcy oraz użytkownika w projekcie, identyfikującymi ryzyko (FMEA – Failure Mode Effect Analysis) – identyfikacja możliwości popełnienia błędu (ryzyka) oraz ich hierarchii i sposobów przeciwdziałania, na tyle na ile jest to możliwe, podsumowującymi wyniki (Balaced Score Card) – mierzenie efektywności projektu oraz trendów rozwojowych.\n206 Czynniki osiągnięcia sukcesu i wady metodyki Six Sigma\nsukces możliwy jest jedynie w przypadku właściwego procesu realizacji, czyli przestrzegania szczegółowych, detalicznych i bardzo restrykcyjnych zaleceń metodycznych i prawidłowej adaptacji do specyficznych warunków panujących w firmie. Ponieważ metoda opiera się na zjawiskach mierzalnych o rozkładzie normalnym, a w gospodarczej rzeczywistości taki rozkład rzadko występuje, to wyniki – pomimo najlepszych intencji – nie wychodzą jedynie nadążają za wielkością 6 sigma, a raczej nigdy jej nie osiągają. Drugim problemem jest tu dążenie do minimalizacji odległości od wielkości planowanych – tańsze jest i chyba częściej spotykane w innych metodykach założenie o minimalnym poziomie zaspokojenia tej zgodności z oczekiwaniami klienta, jest to metoda kosztowna – ponieważ występuje konieczność przeszkolenia własnych pracowników w zakresie wdrożenia metody lub skorzystania z profesjonalistów w tym zakresie. Ale jednocześnie poniesione nakłady zwracają się najczęściej już po pół roku,\n207 Czynniki osiągnięcia sukcesu i wady metodyki Six Sigma\njak inne metodyki zarządzania projektami dla osiągnięcia sukcesu Six Sigma potrzebuje: zaangażowania w projekcie najwyższego kierownictwa oraz pracowników – odpowiednio zmotywowanych (zwłaszcza dla zadań wykraczających poza czas pracy lub wymagających podniesienia kwalifikacji), wykorzystania w nim najbardziej utalentowanych pracowników do stworzenia kadry wdrażającej (tzw. mistrzów czarnych pasów (master black belts) i noszących czarne pasy (black belts)), stworzenia infrastruktury zarządzania dostosowanej do wspierania wdrożenia, ciągłej kontroli zachodzących zmian oraz odpowiedniej polityki informacyjnej - szerzenia wiedzy na temat zasad funkcjonowania Six Sigma, osiągnięcie poziomu 6 sigma jest szalenie trudne (polskie firmy posiadają procesy na poziomie 2-3), poprzez doskonalenie procesów wystarczy jednak dojść do poziomu 4 sigma, by konkurować na rynkach światowych (to już daje ilość popełnianych błędów w procesie np. produkcyjnym na poziomie mniejszym niż 1%),\n208 Czynniki osiągnięcia sukcesu i wady metodyki Six Sigma\nmetodyka ta jest nie lepsza niż TQM, chociaż olbrzymia rolę odgrywają w niej zaawansowane metody statystyczne wykorzystywane dla poprawy jakości. Problem polega jednak jak zwykle we właściwym jej zastosowaniu – jeżeli takie nastąpi, to można powiedzieć, że Six Sigma ma krótszy horyzont czasowy dla uzyskania efektów, dzięki lepszemu zdyscyplinowaniu i wyższemu tempu realizacji, zakres zastosowania metody jest bardzo szeroki – można ja stosować wszędzie tam, gdzie występują procesy (przedsiębiorstwa produkcyjne, banki, urzędy itp.). Przed jej wdrożeniem zawsze należy jednak badać specyfikę danej branży (np. kwestie zachowania bezpieczeństwa) oraz efektywność ekonomiczną jej wdrożenia – relację potencjalnych efektów do poniesionych nakładów,\n209 Czynniki osiągnięcia sukcesu i wady metodyki Six Sigma\nmetodyka ta może być zastosowana zarówno w całej firmie, jak i jednym jej dziale lub dla usuwania problemów związanych z jednym procesem. Mogą to być procesy związane zarówno ze sferą materialną (np. produkcją) lub z informacyjną (administracja), metodyce zarzuca się: brak oryginalności, z powodu oparcia na zdroworozsądkowych założeniach praktycznych; wątpliwe zyski z zastosowania metody (dużo firm rezygnuje z jej stosowania), spadek zadowolenia pracowników (nadmierny formalizm wymusza dokładność działania i nie daje możliwości twórczego potraktowania projektu, co powoduje tłumienie innowacyjności) oraz skupienie się na produkcie, który będzie przynosił zyski\n210 System zarządzania jakością według standardów ISO\n…Norma jest to dokument przyjęty na zasadzie konsensusu i zatwierdzony przez upoważniona do tego jednostkę organizacyjną, ustalający – do powszechnego i wielokrotnego użytkowania – zasady, wytyczne lub charakterystyki odnoszące się do różnych rodzajów działalności lub ich wyników i zmierzający do uzyskania optymalnego stopnia uporządkowania w określonym zakresie. Zaleca się, aby normy były oparte na osiągnięciach zarówno, nauki, techniki, jak i praktyki oraz miały na celu uzyskanie optymalnych korzyści społecznych…\n211 System zarządzania jakością według standardów ISO\nZ przytoczonej definicji wynikają główne zadania normy: stworzenie punktu nowoczesnego odniesienia dla realizacji projektów, ale tez zagrożenia – norma powinna być ciągle monitorowana, poprawiana i unowocześniana, żeby mogła prawidłowo pełnić swą rolę i spełniać oczekiwania użytkowników. Norma może zostać odniesiona do wielu działań realizowanych przez organizację od projektowania, po procesy produkcyjne czy też dystrybucję. Przyporządkowane omawianym normom zarządzanie jakością bezpośrednio odnosi się do zarządzania procesami. Procesy i wszelkie czynności składające się na nie muszą być szczegółowo analizowane, co w rezultacie ma doprowadzić do wykrycia potencjalnie w nich występujących błędów i ich eliminacji, bądź przynajmniej minimalizacji. Norma służy jako pewien punkt odniesienia, niespełnienie jej oznacza jednocześnie niespełnienie wymogów jakości.\n212 System zarządzania jakością według standardów ISO\nNormy mają różny charakter, normy związane z analizą, projektowaniem i wdrażaniem systemów informatycznych np. (ISO 9001:2000) jest norma organizacyjną a nie techniczną. Ze względu na uniwersalny charakter musi być dostosowana do konkretnego obiektu – uwzględniać bieżące i przyszłe potrzeby klienta, propagować sposoby utrzymania zaangażowania zespołów zadaniowych, propagować podejście procesowe, dynamizować proces usprawniania organizacji, sformalizować proces podejmowania decyzji – oparcie ich na bazie faktograficznej oraz uwzględniać prawidłowe relacje z kontrahentami. Spełnienie norm jest stwierdzane w procesie certyfikacji. Poprzedzony on jest: zaprojektowaniem systemu zarządzania jakością i jego udokumentowanie, wdrożenie systemu zarządzania jakością, z możliwością oceny jego skuteczności, przeprowadzenia certyfikacji (audyt teoretycznych założeń systemu zarządzania jakością i jego dokumentacji, audyt zgodności założeń i dokumentacji z faktycznym działanie wdrożonego systemu zapewniania jakości).\n213 Zalety systemu zarządzania jakością według standardów ISO\nGłówne zalety korzystania z systemu normalizacji mogą być więc sformułowane w sposób następujący: rozpoznawalność i uznanie świecie, przedstawienie w postaci wymagań i zaleceń - całości prac od wymagań użytkownika począwszy, poprzez projektowanie, wykonanie, wdrażanie, eksploatację i ciągłe doskonalenie, rozdziela prace systemowe od merytorycznych, wprowadza formalizację prac oraz procesów (struktury organizacyjnej, obowiązków, kompetencji, procesów podstawowych, procesów pomocniczych), zaleca uporządkowanie infrastruktury związanej z projektem, wprowadza konieczność oceny okresowej satysfakcji klientów, systemu zarządzania jakością, poziomu i kwalifikacji kontrahentów itp., wprowadza możliwość odtworzenia w dowolnym czasie zdarzeń uprzednich, wpływających na jakość wytwarzanego produktu lub usługi.\n214 System zarządzania jakością według standardów ISO\nDo podstawowych ograniczeń stosowania standardów ISO należy zaliczyć m.in.: zbytnia formalizację postepowania, co zwiększa koszty funkcjonowania organizacji, wysokie koszty zaprojektowania, udokumentowania, wdrożenia i certyfikacji systemów zapewnienia jakości, wydłuża czas wprowadzania nowych członków do zespołów zadaniowych (muszą się uczyć systemu zarządzania jakością opartego o normę).\n215 Witold Chmielarz - Wydział Zarządzania UW