Podstawy merytoryczne dla wykładu: "Standardy dla projektów informatycznych w administracji na

Transkrypt

1 Podstawy merytoryczne dla wykładu: "Standardy dla projektów informatycznych w administracji na przykładzie ZUS" Niniejszy dokument zawiera podstawy merytoryczne dla wykładu "Standardy dla projektów informatycznych w administracji na przykładzie ZUS". Wykład ma przedstawić cztery podstawowe zagadnienia: Działania standaryzujące ZUS Ryzyka i straty wynikające z braku standardów w instytucjach Korzyści z wdrażania standardów w ZUS. Mapę standardów ZUS. Spójne i czytelne zaprezentowanie powyższych zagadnień wymaga opracowania pewnego modelu obrazującego stopnie standaryzacji instytucji w różnych obszarach związanych z IT wraz określeniem możliwych działań usprawniających, ryzyk, strat i korzyści. Efektem tego będzie pełna mapa standardów wraz z opisami jej obszarów. Wykład powinien być ekstraktem z tej mapy dostosowanym do audytorium. Obszar zastosowania modelu Proponowany w niniejszym dokumencie model odnosi się do trzech podstawowych obszarów związanych ze standaryzacją procesu informatyzacji instytucji: 1. Wymiarowanie i budżetowanie projektów 2. Metodyka analizy i zarządzanie wymaganiami 3. Standaryzacja technologiczna: standaryzacja dokumentacji projektowej i repozytorium architektoniczne Poza powyższymi obszarami istnieje jeszcze oczywiście proces Zarządzania, który spina powyższe obszary zapewniając obieg informacji oraz monitorowanie i rozliczanie prac projektowych. Modelem bazowym dla definiowania procesów zarządzania stosowanym w praktyce w wielu instytucjach jest Prince2. Zastosowanie tego lub innego podobnego modelu jest warunkiem koniecznym by móc należycie realizować proces informatyzacji instytucji. Jednakże wdrożenie procesów zarządzania w instytucji nie jest warunkiem wystarczających do powodzenia tego procesu. Proces informatyzacji, jak każda działalność z dziedziny inżynierii, dla skutecznego i efektywnego zastosowania wymaga użycia odpowiednich standardów. 1

2 Legenda W tabelach zastosowano następującą gradację kolorów: czerwony istotne ryzyka ciemnoczerwony/ceglany ryzyka drobne lub akceptowalne, także korzyści, które de facto są ryzykami ciemnozielony korzyści oczywiste lub drobne, także ryzyka, które de facto są korzyściami zielony istotne korzyści 1. Wymiarowanie i budżetowanie projektów Poniższa tabela przedstawia stopnie rozwoju standaryzacji zasad budżetowania projektów wraz z określeniem ryzyk i korzyści dla każdego stopnia. ZUS aktualnie wdraża stopień: 3. Stopień standaryzacji Stan standaryzacji Ryzyka Korzyści 0 Zerowy = brak standardów. Przyjęte budżety projektów są Delegowanie odpowiedzialności za Budżetowanie opiera się na opinii jednego nieweryfikowalne w sposób budżetowanie do konkretnej grupy lub kilku specjalistów wykorzystujących obiektywny. osób. metodę delficką lub per analogia. Przyjęte budżety projektów są niedoszacowane lub przeszacowane na poziomie nawet do 400%. Praktycznie pewnie jest niezrealizowanie projektu zgodnie z przyjętymi założeniami odnośnie zakresu, czasu i budżetu. 1 Początkujący = nieujednolicone stosowanie wielu różnych metod z zakresu miar oprogramowania: różne metody punktów funkcyjnych rozmiaru funkcjonalnego, punkty złożoności przypadków użycia, liczby określonych komponentów oprogramowania, liczba linii kodu, Bez wspólnego punktu odniesienia jaką jest Strategia Stosowania miar rozmiaru oprogramowania jednego projektu jest nieporównywalny z rozmiarem każdego innego. Brak możliwości ujednoliconego zbierania danych statystycznych Możliwość eksperymentowania z różnymi sposobami określania rozmiaru oprogramowania. Ułatwione negocjacje rozmiaru zleceń w relacji z wykonawcami w danym projekcie. 2

3 roboczogodziny poświęcone na realizację. 2 Zdefiniowany = ujednolicone stosowanie jednej metody uznanej w standardzie ISO/IEC wraz z przyjętą Strategią Stosowania wraz ze zbieraniem danych statystycznych. 3 Zaawansowany = ujednolicone stosowanie jednej metody uznanej w standardzie ISO/IEC wraz z wykorzystaniem własnych i branżowych danych statystycznych związanych z cyklem produkcji oprogramowania. 4 Strategiczny = podejmowanie celowych działań optymalizacyjnych w procesach zamawiania i produkcji oprogramowania wynikających z analizy danych historycznych Stosowanie miar rozmiaru oprogramowania spoza normy ISO/IECO niesienie ryzyko uzależnienia kosztów od zakładanej a priori produktywności lub nieujęcia w rozmiarze wszystkich aspektów oprogramowania. Możliwość odniesienia się do danych branżowych. Możliwość porównywania różnych projektów o zbliżonej technologii. Możliwość obiektywnej weryfikacji budżetu przez niezależnych ekspertów. Duże ułatwienie procesów negocjacji warunków realizacji zleceń. Możliwość nakładania wymogów produktywności wobec wykonawców. Możliwość nieustannej poprawy efektywności wydawania środków na informatyzację. 3

4 2. Metodyka analizy i zarządzanie wymaganiami Poniższa tabela przedstawia stopnie rozwoju standaryzacji analizy i zarządzania wymaganiami wraz z określeniem ryzyk i korzyści dla każdego stopnia. ZUS aktualnie wdraża stopień: 2 3. Stopień standaryzacji Stan standaryzacji Ryzyka Korzyści 0 Zerowy = brak analizy i Całkowite uzależnienie od dostawcy. W początkowej fazie iluzoryczne niższe koszty zarządzania wymaganiami. Ogromnie trudna lub niemożliwa wytworzenia systemu informatycznego. Jednak już integracja rozwiązań. przy pierwszych błędach i rozszerzeniach iluzja Brak możliwości szacowania złożoności oprogramowania, a więc kosztów, ta znika, a korzyść zamienia się w ryzyko. Brak udokumentowanego związku między systemem informatycznym a procesami biznesowymi. Brak możliwości analizy luk funkcjonalnych systemu. zasobów, terminów. Całkowity brak punktu odniesienia dla: o zarządzania wymaganiami, o zarządzania zmianą, o testów i zarządzania błędami. Brak możliwości weryfikacji systemu. Brak formalnej i logicznej podstawy do wykazania błędów. Praktyczna niemożność reużycia elementów, co skutkuje powielaniem i nieoptymalnością systemu. 4

5 1 Początkujący = analiza i zarządzanie wymaganiami istnieje, ale brak standardu. Sprowadza się to w praktyce do braku jednolitości analizy, standardów przypadkowych i niekonsekwentnie stosowanych, różnych dla różnych autorów. 2 Zdefiniowany = istnieje kompletny standard analizy i zarządzania wymaganiami, pokrywający wszystkie kluczowe aspekty, ale powstały niekoniecznie w oparciu o najlepsze standardy zewnętrzne. Duże uzależnienie od dostawcy. Bardzo utrudniona integracja rozwiązań. Niska jakość dokumentacji i prawdopodobnie samego systemu. Utrudnione szacowanie złożoności oprogramowania, a więc kosztów, zasobów, terminów. Trudna weryfikacja systemu najczęściej fragmentaryczna, brak możliwości globalnej weryfikacji, w tym weryfikacji spójności i kompletności. Liczba błędów jest potencjalnie duża, w tym analiza narażona jest na sprzeczności i niedopowiedzenia. Luki i redundancje w analizie są praktycznie nieuniknione. Niski wskaźnik reużycia elementów, co skutkuje redundancjami i nieoptymalnością systemu. "Odkrywanie koła" 1 możliwe nawet w ramach jednego systemu, jednego wykonawcy. Tworzenie dokumentacji nie zawsze optymalnej w oparciu o nie zawsze optymalne metodyki, standardy i wzorce. "Odkrywanie koła" możliwe w zakresie standardu. Jest jakikolwiek punkt odniesienia i dokumentacja. Oczywiście nie jest to wystarczające do optymalnego wytworzenia systemu informatycznego wysokiej jakości. Duże uniezależnienie od dostawcy. Możliwość zlecania utrzymania, rozszerzeń, a nawet weryfikacji do dowolnego podmiotu (dokumentacja zrozumiała nie tylko dla autorów). Możliwość analiz rozwiązań pod kątem optymalnej integracji. Jednolita dokumentacja, o wyższej jakości. Możliwość kompleksowej i globalnej weryfikacji systemu. Możliwa weryfikacja dokumentacji 1 "Odkrywanie koła" opracowywanie wcześniej opracowanych, znanych elementów 5

6 i użycia standardu na podstawie ujednoliconej check listy. Duża odporność na błędy. Możliwa jest analiza luk systemu. Możliwość szacowania złożoności oprogramowania, co przekłada się na obiektywne i dokładne szacowanie kosztów, zasobów, terminów. Ułatwione lub wymuszone przez standard reużycie elementów: wspólnych funkcjonalności, bazowych komponentów etc. "Odkrywanie koła" znikome w zakresie zawartości merytorycznej. 3 Zaawansowany = istnieje Konieczność edukacji personelu. Jednak Jak wyżej oraz: kompletny standard, już przy pierwszych testach Ponieważ standard jest oparty o ogólnie przyjęte dodatkowo zdefiniowany i rozszerzeniach to ryzyko przeistacza się w i wielokrotnie przetestowane standardy w oparciu o najlepsze korzyść. Dobrze wyedukowany personel to zewnętrzne (paradygmaty, metodyki, notacje, standardy zewnętrzne: wartość sama w sobie, czynne wzorce, praktyki), to proces wytwarzania jest paradygmaty, metodyki, uczestnictwo w procesie wytwarzania optymalny i stoi na najwyższym znanym poziomie. notacje, wzorce, praktyki. oprogramowania i większa świadomość i kontrola nad wytwarzanym systemem informatycznym. Jakość, zakres i "głębokość" dokumentacji jest odpowiednio wysoka. Daje to dużą przyspieszenie przy wytwarzanie oprogramowania i zwinność przy zlecaniu zmian/rozszerzeń. "Odkrywanie koła" znikome zarówno w ramach zawartości merytorycznej, jak i standardu. Analiza stanowi doskonałą podstawę do wytworzenia kolejnych etapów i warstw wytwarzania SI: projektowej, technicznej, implementacji itd. Dalsze etapy dokumentacji (przy nałożeniu na nie równie restrykcyjnych standardów) mogą być wykonane na równie wysokim poziomie. 4 Optymalizowany = jak Brak. Jak wyżej oraz: 6

7 wyżej, dodatkowo cyklicznie rekontrolowany i optymalizowany, także w oparciu o własne doświadczenia. 3. Standaryzacja technologiczna Możliwość nieustannej poprawy efektywności i jakości dokumentacji poprzez autokorektę standardów, na podstawie cudzych i własnych doświadczeń Standaryzacja dokumentacji projektowej Poniższa tabela przedstawia stopnie rozwoju standaryzacji dokumentacji projektowej (technicznej) wraz z określeniem ryzyk i korzyści dla każdego stopnia. ZUS aktualnie wdraża stopień: 2 3. Stopień standaryzacji Stan standaryzacji Ryzyka Korzyści 0 Zerowy = brak Całkowite uzależnienie od dostawcy. W początkowej fazie iluzoryczne niższe koszty dokumentacji projektowej Ogromnie trudna lub niemożliwa wytworzenia systemu informatycznego. Jednak już integracja rozwiązań. przy pierwszych błędach i rozszerzeniach iluzja Brak kontroli wydatków na infrastrukturę. ta znika, a korzyść zamienia się w ryzyko. Brak możliwości weryfikacji, czy rozwiązania pozwalają na ekonomicznie korzystne rozwijanie w przyszłości. Brak możliwości poprawnego zrozumienia architektury/konstrukcji systemu informatycznego. Brak możliwości śladowania: wnioskowania, które elementy (np. kodu, infrastruktury) działającego systemu są odpowiedzialne za realizację danej funkcjonalności. Utrudniona identyfikacja błędów systemu informatycznego. Praktyczna niemożność reużycia 7

8 1 Początkujący = dokumentacja projektowa istnieje, ale brak standardu projektowania. Sprowadza sie to w praktyce do braku jednolitości w projekcie, standardów przypadkowych i niekonsekwentnie stosowanych, różnych dla różnych autorów. 2 Zdefiniowany = istnieje pełny standard projektowania, pokrywający wszystkie kluczowe aspekty. Duże uzależnienie od dostawcy. Bardzo utrudniona integracja rozwiązań. Niska jakość dokumentacji i prawdopodobnie samego systemu. Niepełna kontrola wydatków na infrastrukturę. Utrudnienia w weryfikacji, czy rozwiązania pozwalają na ekonomicznie korzystne rozwijanie w przyszłości. Niski wskaźnik reużycia elementów, co skutkuje redundancjami i nieoptymalnością systemu. "Odkrywanie koła" możliwe nawet w ramach jednego systemu, jednego wykonawcy. Tworzenie dokumentacji nie zawsze optymalnej w oparciu o nie zawsze optymalne metodyki, standardy i wzorce. "Odkrywanie koła" możliwe w zakresie standardu. Jest jakikolwiek punkt odniesienia i dokumentacja. Oczywiście nie jest to wystarczające do optymalnego wytworzenia systemu informatycznego wysokiej jakości. Duże uniezależnienie od dostawcy. Możliwość zlecania utrzymania, rozszerzeń, a nawet weryfikacji do dowolnego podmiotu (dokumentacja zrozumiała nie tylko dla autorów). Możliwość analiz rozwiązań pod kątem optymalnej integracji. Jednolita dokumentacja, o wyższej jakości. Możliwość kompleksowej i globalnej weryfikacji systemu. Możliwa weryfikacja dokumentacji i użycia standardu na podstawie ujednoliconej check listy. Duża odporność na błędy. Możliwość kontroli wydatków na infrastrukturę. Możliwość kontroli, czy rozwiązania pozwalają na ekonomicznie korzystne rozwijanie w przyszłości. 8

9 3 Zaawansowany = istnieje pełny standard projektowania, zdefiniowany w oparciu o najlepsze standardy zewnętrzne: paradygmaty, metodyki, notacje, wzorce, praktyki. Konieczność edukacji personelu. Jednak już przy pierwszych testach i rozszerzeniach to ryzyko przeistacza się w korzyść. Dobrze wyedukowany personel to wartość sama w sobie, czynne uczestnictwo w procesie wytwarzania oprogramowania i większa świadomość i kontrola nad wytwarzanym systemem informatycznym. Ułatwione lub wymuszone przez standard reużycie elementów: wspólnych funkcjonalności, bazowych komponentów etc. "Odkrywanie koła" znikome w zakresie zawartości merytorycznej. Jak wyżej oraz: Ponieważ standard jest oparty o ogólnie przyjęte i wielokrotnie przetestowane standardy zewnętrzne (paradygmaty, metodyki, notacje, wzorce, praktyki), to proces wytwarzania jest optymalny i stoi na najwyższym znanym poziomie. Jakość, zakres i "głębokość" dokumentacji jest odpowiednio wysoka. Daje to dużą przyspieszenie przy wytwarzanie oprogramowania i zwinność przy zlecaniu zmian/rozszerzeń. "Odkrywanie koła" znikome zarówno w ramach zawartości merytorycznej, jak i standardu. 4 Optymalizowany = jak wyżej, dodatkowo cyklicznie rekontrolowany i optymalizowany, także w oparciu o własne doświadczenia. Brak. Jak wyżej oraz: Możliwość nieustannej poprawy efektywności i jakości dokumentacji poprzez autokorektę standardów, na podstawie cudzych i własnych doświadczeń. 9

10 3.2. Repozytorium architektoniczne Poglądowa mapa ewolucji repozytorium architektonicznego: Poziom Status Repozytoria cząstkowe Standardy dla repozytoriów cząstkowych Repozytorium architektoniczne Standard architektoniczny Najlepsze standardy architektoniczne zewnętrzne 0 Zerowy 1 Początkujący + 2 Zdefiniowany/Zaawansowany + + warstwowo 3 Scalony Zunifikowany Zaawansowany Optymalizowany ZUS aktualnie wdraża stopień: 2 4. Rekontrola i optymalizacja architektury Poniższa tabela przedstawia stopnie rozwoju repozytorium architektonicznego i standardu dla niego wraz z określeniem ryzyk i korzyści dla każdego stopnia. Stopień standaryzacji Stan standaryzacji Ryzyka Korzyści 0 Zerowy = brak repozytoriów. Całkowite uzależnienie od dostawcy. Ogromnie trudna lub niemożliwa integracja rozwiązań. Brak kontroli wydatków na infrastrukturę. Brak udokumentowanych relacji między warstwami. Trudna integracja warstw. 10 W początkowej fazie iluzoryczne niższe koszty wytworzenia systemu informatycznego. Jednak już przy pierwszych błędach i rozszerzeniach iluzja ta znika, a korzyść zamienia się w ryzyko.

11 1 Początkujący = są cząstkowe repozytoria: rozproszone i/lub niespójne i/lub nieskorelowane; brak standardów dla repozytoriów: jednolitych dla poszczególnych obszarów i warstw. 2 Zdefiniowany/Zaawansowany warstwowo = są cząstkowe repozytoria: rozproszone i/lub niespójne i/lub nieskorelowane; są standardy dla repozytoriów: jednolite dla poszczególnych obszarów i warstw. 3 Scalony = jest repozytorium architektoniczne: nierozproszone i spójne; są standardy dla repozytoriów: jednolite dla poszczególnych obszarów i warstw; brak jednolitego standardu dla architektury. 4 Zunifikowany = jest repozytorium Brak możliwości śladowania i weryfikacji systemu w głąb. Duże uzależnienie od dostawcy. Bardzo utrudniona integracja rozwiązań. Niska jakość dokumentacji i prawdopodobnie samego systemu. Nie zawsze udokumentowane relacje między warstwami. Utrudniona weryfikacja systemu w głąb. Nie zawsze udokumentowane relacje między warstwami. Utrudniona weryfikacja systemu w głąb. Dodatkowe koszty scalania. Koszty te szybko jednak zwracają się. Problemy organizacyjne, logistyczne i technologiczne. Problemy te są do okiełznania, dodatkowo, po niedługim czasie przeistaczają się one w korzyści. Konieczność edukacji personelu. Jednak już przy pierwszych testach Jest jakikolwiek punkt odniesienia i dokumentacja. Oczywiście nie jest to wystarczające do optymalnego wytworzenia systemu informatycznego wysokiej jakości. Uniezależnienie od dostawcy. Możliwa integracja rozwiązań. Możliwość kontroli wydatków na infrastrukturę. Możliwość kontroli, czy rozwiązania pozwalają na ekonomicznie korzystne rozwijanie w przyszłości. Jak wyżej oraz: Jedno repozytorium architektoniczne to jedna scentralizowana "wiedza o" systemie informatycznym. Uproszczenia w administrowaniu i zarządzaniu jednym repozytorium. Jak wyżej oraz: Jedno ustandaryzowane repozytorium 11

12 architektoniczne: nierozproszone i spójne; jest jednolity standard dla architektury. i rozszerzeniach to ryzyko przeistacza się w korzyść. Dobrze wyedukowany personel to wartość sama w sobie, czynne uczestnictwo w procesie wytwarzania oprogramowania i większa świadomość i kontrola nad wytwarzanym systemem informatycznym. architektoniczne to jedna scentralizowana "wiedza o", a więc i "władza nad" systemem informatycznym nad wytwarzaniem, rozszerzeniami i utrzymaniem systemu informatycznego. Możliwość dynamicznej ewidencji infrastruktury: sprzętu i oprogramowania. Możliwość pełnej identyfikacji i kontroli wszystkich zależności pomiędzy elementami i warstwami systemu. Możliwość postawienia tak ekstremalnych zapytań jak np.: które procesy biznesowe nie będą mogły być w pełni zrealizowane w przypadku awarii urządzenia kryptograficznego "Delta 1" lub serwera "H 001"). Możliwa weryfikacja systemu w głąb. Możliwość reużycia bloków: elementów wspólnych oraz bazowych. 5 Zaawansowany = Jak wyżej. Jak wyżej oraz: jest repozytorium Ponieważ standard jest oparty o ogólnie architektoniczne: przyjęte nierozproszone i spójne; i wielokrotnie przetestowane standardy jest jednolity standard dla zewnętrzne (paradygmaty, metodyki, architektury, zdefiniowany notacje, wzorce, praktyki), to proces w oparciu o najlepsze wytwarzania jest optymalny i stoi na standardy zewnętrzne: najwyższym znanym poziomie. paradygmaty, metodyki, Jakość, zakres i "głębokość" dokumentacji notacje, wzorce, praktyki. jest odpowiednio wysoka. Daje to dużą przyspieszenie przy wytwarzanie oprogramowania i zwinność przy zlecaniu zmian/rozszerzeń. 6 Optymalizowany = jak wyżej, Brak. Jak wyżej oraz: 12

13 dodatkowo cyklicznie rekontrolowany i optymalizowany, także w oparciu o własne doświadczenia. Możliwość nieustannej poprawy efektywności i jakości dokumentacji poprzez autokorektę standardów, na podstawie cudzych i własnych doświadczeń. 13