Podręcznik stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa

Wielkość: px
Rozpocząć pokaz od strony:

Download "Podręcznik stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa"

Transkrypt

1 29/11/ Załącznik nr 1 do Załącznika nr 4C Podręcznik stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa v1.0

2 Spis treści Wstęp... 4 Zakres stosowania metody PF IFPUG... 5 Zasady stosowania metody PF IFPUG... 7 Wprowadzenie do punktów funkcyjnych... 7 Wstęp do metody PF IFPUG... 7 Metoda PF IFPUG w ARiMR... 9 Metoda PF IFPUG zasady Identyfikacja modelu danych IFPUG Identyfikacja modelu funkcjonalnego IFPUG Wyliczenie rozmiaru funkcjonalnego elementów modelu IFPUG Metoda PF IFPUG z rozszerzeniem opracowanym przez organizację NESMA Wyliczanie zmian modelu danych Wyliczanie zmian modelu funkcji Zasady stosowania współczynnika VAF Proces szacowania rozmiaru oprogramowania / zmiany oprogramowania Zasady wykorzystania metody PF IFPUG w danym projekcie... Błąd! Nie zdefiniowano zakładki. Zasady tworzenia i utrzymywania modelu artefaktów PF IFPUG Zasady prezentacji wyników szacowania PF IFPUG w dokumentacji ofertowej Proces weryfikacji szacowania Lista kontrola weryfikacji modelu danych IFPUG Lista kontrola weryfikacji modelu funkcji IFPUG Podział oprogramowania względem granic i współczynniki VAF System informatyczny - EBS... Błąd! Nie zdefiniowano zakładki. System informatyczny - ZSZiK System informatyczny - Platforma aplikacyjna... Błąd! Nie zdefiniowano zakładki. System informatyczny - System Informacji zarządczej... Błąd! Nie zdefiniowano zakładki. System informatyczny - OFSA... Błąd! Nie zdefiniowano zakładki. System informatyczny - SI-Agencja... Błąd! Nie zdefiniowano zakładki.

3 Zasady interpretacji metody PF IFPUG dla specyficznych typów funkcjonalności i zmian Stosowanie PF IFPUG Stosowanie PF IFPUG dla złożonych funkcjonalności Stosowanie PF IFPUG dla funkcjonalności sterowanych procesami Stosowanie PF IFPUG dla złożonych raportów Stosowanie PF IFPUG dla złożonego interfejsu użytkownika Stosowanie PF IFPUG dla złożonych procesów wsadowych Stosowanie PF IFPUG dla algorytmów... 37

4 WSTĘP Niniejszy Podręcznik ma na celu opisanie zakresu oraz zasad stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa. Niniejszy Podręcznik definiuje również zasady utrzymywania dokumentacji będącej podstawą do szacowania oraz zasady prezentacji wyników szacowania. Metoda Punktów Funkcyjnych IFPUG (PF IFPUG) jest metodą pomiaru rozmiaru funkcjonalnego oprogramowania z perspektywy wymagao użytkownika. Metoda ta jest utrzymywana i rozwijana przez organizację International Function Point Users Group (www.infpug.org). Zasady wykorzystania metody PF IFPUG w ARiMR są opisane w dokumencie Function Point Counting Practices Manual w wersji 4.3 publikowanym przez organizację IFPUG między innymi w języku angielskim. Dodatkowym dokumentem rozszerzającym zasady opisane w w/w dokumencie jest publikacja organizacji NESMA (Netherlands Software Metrics Association) Function Point Analysis for Software Enhancement (www.nesma.org, dokument dostępny w języku angielskim). Dodatkowe zasady opisane w dokumencie organizacji NESMA mają zastosowanie dla szacowania zmian oprogramowania. W/w dokumenty są dokumentami bazowymi dla niniejszego Podręcznika, co oznacza, iż w przypadku, gdy niniejszy Podręcznik nie zawiera jakiejś informacji odnośnie zastosowania metody PF IFPUG w danej sytuacji to należy odwoład się do tych dokumentów. Niniejszy Podręcznik nie jest dokumentem zastępującym w/w dokumenty oznacza to, iż osoby dokonujące szacowania rozmiaru oprogramowania zgodnie z zasadami metody PF IFPUG powinny byd również z nimi zapoznane. Załączniki do niniejszego dokumentu: przykład projektu Enterpise Architect "ARiMR_IFPUG.eap", szablon dokumentu "ARiMR_IFPUG_Wycena Zmiany". Źródła wykorzystane w opracowaniu: - Podręcznik Metody w wersji 4.3 i inne materiały dostępne dla członków organizacji, materiały publiczne, M. A. Parthasarathy, Practical Software Estimation, Addison-Wesley & Infosys 2007, ISBN M. Mundschuh, C. Dekkers, The IT Measurement Compendium, Springer 2008, e-isbn Capers Jones, Estimating Software Costs, Bringing Realism To Estimating, Second Edition, The McGraw Hill Companies 2007, ISBN 13: , ISBN 10: S. McConnell, Software Estimation: Demystifying the Black Art, Microsoftpress 2006, ISBN

5 ZAKRES STOSOWANIA METODY PF IFPUG Rozmiar funkcjonalny oprogramowania jest definiowany, jako rozmiar oprogramowania opracowanego w wyniku implementacji konkretnego zbioru wymagao funkcjonalnych użytkownika. Wymagania funkcjonalne użytkownika są podzbiorem wymagao użytkownika na dane oprogramowanie. Wymagania użytkownika dla oprogramowania są też podzbiorem wymagao dla projektu / modyfikacji w ramach, których to oprogramowanie jest realizowane. Oznacza to, iż nie wszystkie prace związane z realizacją oprogramowania, projektu / modyfikacji, mogą byd oszacowane metodą PF IFPUG. Uwzględniając powyższe, metoda PF IFPUG, pozwala oszacowad rozmiar funkcjonalny oprogramowania lub rozmiar funkcjonalny zmiany oprogramowania przy założeniu, iż definicja funkcjonalności nowej lub zmienianej wynika z wymagao funkcjonalnych użytkownika. Rozmiar funkcjonalny oprogramowania jest niezależny od wymagao niefunkcjonalnych, w tym od technologii, architektury i sposobu realizacji danego oprogramowania. Oznacza to również, iż wszystkie zadania projektu / modyfikacji mające na celu wprowadzenie / zmianę technologii, architektury czy sposobu dostarczania oprogramowania nie podlegają szacowaniu metodą PF IFPUG. Jednakże standardowe prace wynikające z uwzględniania wymagao niefunkcjonalnych w trakcie realizacji zmian funkcjonalnych traktuje się jako prace wliczone w cenę punktu funkcyjnego: Migracji danych niezbędnej dla uruchomienia nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji danych w bazie danych na potrzeby działania nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji parametrów definiujących działanie aplikacji (w kontekście technologicznym jak i biznesowym) niezbędnych dla działania nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji słowników wspierających działanie aplikacji (w kontekście technologicznym jak i biznesowym) niezbędnych dla działania nowej / zmodyfikowanej funkcjonalności, Optymalizacji oprogramowania / struktury bazy danych w zakresie obowiązującego SLA, Prac konfiguracyjnych dotyczących elementów architektury, infrastruktury i oprogramowania standardowego niezbędnych dla uruchomienia nowej / zmodyfikowanej funkcjonalności, Zmiana wyglądu, koloru, układu kontrolek i danych na interfejsie użytkownika wynikające z nowych / zmodyfikowanych funkcjonalności. Zadania, których głównym celem jest realizacja prac niefunkcjonalnych są szacowane w oparciu o ekspercką wycenę roboczogodzin. Zadania te dotyczą w szczególności: Wprowadzenia lub zmiany elementów technologii, Wprowadzenia lub zmiany elementów architektury, Wprowadzenia lub zmiany elementów infrastruktury Migracji danych o dużej skali wynikającej ze zmian infrastruktury, Optymalizacji oprogramowania / struktury bazy danych w ramach nowego SLA, Prac konfiguracyjnych dotyczących elementów architektury i oprogramowania standardowego wynikających ze zmian infrastrukturalnych oraz architektonicznych, Wygenerowania niestandardowych raportów ad-hoc w oparciu o istniejące w oprogramowaniu dane. Powyższe wykluczenie, nie oznacza jednakże, iż wyżej wymienione prace związane z opracowaniem oprogramowania nie są w założeniu umowy pomiędzy ARiMR a Wykonawcą wliczone w cenę punktu funkcyjnego jest to jednak zagadnienie odrębne od samego wyznaczania rozmiaru funkcjonalnego oprogramowania lub zmiany oprogramowania.

6 Przykład: W ramach modyfikacji oprogramowania zdefiniowano trzy wymagania funkcjonalne: (1) graficzny status on-line liczby decyzji o przyznaniu płatności w poszczególnych województwach ma prezentowad również liczbę odrzuconych decyzji, (2) dotychczasowa prezentacja liczby przyznanych decyzji ma byd prezentowana na zielono a odrzuconych na czerwono, (3) czas odświeżenia graficznego statusu ma byd obniżony do 2 sekund. W tym przykładzie jedynie wymaganie (1) ma wpływ na rozmiar funkcjonalny zmiany wyliczalny metodą PF IFPUG, realizacja wymagania (2) z założenia, może byd wliczona w cenę jednego punktu funkcyjnego rozmiaru funkcjonalnego, a wymaganie (3) wymaga osobnego oszacowania w innych jednostkach rozliczeniowych np. roboczogodzinach. W ramach funkcjonalności, dla której ma zastosowanie metoda IFPUG zakłada się, iż koszt punktu funkcyjnego określony w umowie pomiędzy ARiMR i Wykonawcą zawiera w sobie koszt całego cyklu wytwórczego związanego z wytworzeniem oprogramowania o złożoności jednego punktu funkcyjnego.

7 ZASADY STOSOWANIA METODY PF IFPUG WPROWADZENIE DO PUNKTÓW FUNKCYJNYCH Metody punktów funkcyjnych to zbiory reguł, których zastosowanie do danego zbioru wymagao funkcjonalnych użytkownika, pozwala wyznaczyd funkcjonalny rozmiar oprogramowania realizującego te wymagania. Oznacza to iż na wejściu danej metody jest podawany zbiór wymagao a na wyjściu oczekiwana jest liczba punktów funkcyjnych wyznaczona dla tego zbioru wymagao. Punkt funkcyjny jest abstrakcyjną miarą, definiowaną, jako jednostka funkcjonalności biznesowej dostarczana przez mierzone oprogramowanie. Oznacza to, iż oprogramowanie o rozmiarze 100 punktów funkcyjnych dostarcza użytkownikowi 100 jednostkowych funkcjonalności biznesowych. Zbiór wymagao funkcjonalnych Metoda PF Liczba PF Wyznaczona liczba punktów funkcyjnych dla danego zbioru wymagao może byd określona mianem nieskorygowanych punktów funkcyjnych lub skorygowanych punktów funkcyjnych. Nieskorygowane punkty funkcyjne to wartośd wynikająca wprost z zastosowania reguł metody dla danego zbioru wymagao funkcjonalnych. Skorygowane punkty funkcyjne uwzględniają dodatkowo reguły określające wpływ wymagao niefunkcjonalnych, środowiska projektu i procesu produkcji - jest to zazwyczaj odpowiednio przekształcona liczba nieskorygowanych punktów funkcyjnych. W dalszej części Podręcznika - o ile nie będzie to określone inaczej - przez określenie "liczba punktów funkcyjnych" należy rozumied nieskorygowaną liczbę punktów funkcyjnych. W przypadku zmian istniejącego oprogramowania, liczba punktów funkcyjnych może dotyczyd samej zmiany jak i rozmiaru oprogramowania po zmianie. W przypadku rozmiaru zmiany, liczba punktów funkcyjnych zmiany wynika wprost z wymagao definiujących zmianę. W przypadku rozmiaru oprogramowania po zmianie - liczba punktów funkcyjnych oprogramowania może pozostad taka sama jak przed zmianą, może się zmniejszyd lub zwiększyd. Przykład: W przypadku oprogramowania A o rozmiarze 100 PF zdefiniowano zmianę o wprowadzająca nowe funkcje o rozmiarze 25 PF. Rozmiar zmiany to 25 PF a rozmiar oprogramowania A po zmianie to 125 PF. W przypadku oprogramowania B o rozmiarze 200 PF zdefiniowano zmianę modyfikującą istniejące funkcje - bez wprowadzania nowych. Rozmiar zmiany określono na 40 PF. Rozmiar oprogramowania B po zmianie to w dalszym ciągu 200 PF. WSTĘP DO METODY PF IFPUG Metoda Punktów Funkcyjnych IFPUG zakłada, iż rozmiar oprogramowania (w postaci liczby nieskorygowanych punktów funkcyjnych) może byd wyznaczony w oparciu o analizę pięciu kluczowych parametrów: funkcji wejścia i wyjścia, zapytao oraz wewnętrznego modelu danych i interfejsów do systemów zewnętrznych. Wybór tych elementów przez twórców metody był podyktowany tym, iż są to parametry znane użytkownikowi funkcjonalnemu oprogramowania (niejako definiują one funkcjonalnośd oprogramowania z jego punktu widzenia). Użyte powyżej pojęcie użytkownik funkcjonalny oznacza zarówno użytkownika w postaci osoby korzystającej z oprogramowania jak i użytkownika w postaci innego oprogramowania / systemu / urządzenia.

8 Jako naczelną zasadę dla stosowania metody PF IFPUG należy podkreślid fakt, iż w/w pięd parametrów oprogramowania musi wynikad wprost z wymagao funkcjonalnych użytkownika oraz musi reprezentowad funkcjonalnośd oprogramowania (rozumianą tu, jako funkcje i dane) dostępną dla użytkownika funkcjonalnego bez odnoszenia się do sposobu implementacji (udostępniania) tej funkcjonalności. Powyższy rysunek przedstawia dwie aplikacje A i B. Aplikacja A udostępnia funkcje wyjścia / wejścia / zapytao użytkownikowi, posiada swoją własną logikę przetwarzania danych oraz wewnętrzne pliki dla przechowywania danych. Aplikacja ta korzysta również z Aplikacji B poprzez określony interfejs wymiany danych. Z punktu widzenia metody PF IFPUG logika biznesowa (logika przetwarzania) jest elementem aproksymowanym przez złożonośd funkcji wejścia / wyjścia / zapytao oraz wewnętrznego modelu danych. Nie podlega ona bezpośredniemu szacowaniu. To ograniczenie oznacza, iż jeśli złożonośd tej logiki wykracza poza zakres stosowalności metody to należy ją dodatkowo oszacowad. W szczególności poza zakres stosowalności metody wykraczają algorytmy związane z przetwarzaniem danych multimedialnych, prognoz pogody, obliczeo naukowych itp. W szczególnych przypadkach niektóre algorytmy stosowane w aplikacjach typowo biznesowych również mogą wykraczad poza zakres stosowalności metody. Zbiór w/w parametrów oprogramowania, czyli zbiór funkcji wejścia, wyjścia, zapytao, modelu danych wewnętrznych i zewnętrznych jest w dalszej części określany, jako model IFPUG, czyli sposób odzwierciedlenia wymagao funkcjonalnych użytkownika w postaci artefaktów definiowanych przez reguły metody PF IFPUG. Metoda PF IFPUG wprowadza również pojęcie granicy oprogramowania. Granica oprogramowania wyznacza zakres szacowanego oprogramowania jak i również służy do dookreślenia funkcji wejścia / wyjścia / zapytao, jako funkcji przenoszących dane z zewnątrz do wewnątrz granicy lub z wewnątrz na zewnątrz granicy. Wewnętrzny model danych jest również traktowany, jako mechanizm utrwalania danych wewnątrz granicy oprogramowania, podczas gdy interfejsy zewnętrzne są modelowane, jako zbiory danych dostępne dla oprogramowania poza jego granicami. Granica danego oprogramowania powinna byd zgodnie z założeniami metody wyznaczona w oparciu o perspektywę jego użytkownika a precyzyjniej jego potrzeb. Oznacza to, iż oprogramowanie objęte granicą powinno realizowad spójne określone cele użytkownika, powinno zawierad logicznie powiązane funkcje i dane zgodnie z potrzebami użytkownika. W żadnym wypadku granica ta nie powinna byd, zatem wyznacza przez ograniczenia technologiczne, infrastrukturalne czy architektoniczne. W przypadku szacowania zmian oprogramowania należy mied na uwadze fakt, iż granica oprogramowania jest czymś niezależnym od zmiany powinna byd zdefiniowana dla danego zmienianego oprogramowania, jako logicznej całości a nie, dla danego zmienianego fragmentu.

9 Ostatnim elementem metody PF IFPUG jest możliwośd skorygowania wyznaczonego rozmiaru oprogramowania za pomocą współczynnika VAF (Value Adjustment Factor). Współczynnik ten jest wyznaczany w oparciu o 14 cech oprogramowania mających odzwierciedlad wymagania niefunkcjonalne. Jest to element opcjonalny metody PF IFPUG. METODA PF IFPUG W ARIMR Procedura zastosowania metody PF IFPUG jest następująca: 1) Pozyskanie dostępnej dokumentacji dla szacowanego oprogramowania 2) Określenie celu i zakresu szacowania celem zdefiniowania granicy oprogramowania 3) Określenie współczynnika VAF w oparciu o przyjętą architekturę i wymagania niefunkcjonalne 4) Określenie w oparciu o dostępną dokumentację zbioru wymagao funkcjonalnych użytkownika 5) Zidentyfikowanie i oszacowanie funkcji wejścia / wyjścia / zapytao oraz modeli danych wewnętrznych i zewnętrznych celem wyliczenia liczby nieskorygowanych punktów funkcyjnych Z punktu widzenia szacowania projektów i modyfikacji w ARiMR kroki te są określane następująco: Ad1) Przez dostępną dokumentację rozumie się istniejąca dokumentację w postaci Analitycznych Opisów Produktów, Analitycznych Opisów Modyfikacji oraz dostępną dla danego projektu / modyfikacji dokumentację definiująca zakres projektu / modyfikacji. Ad2) Granice szacowanego oprogramowania opracowane są przez ARiMR i są zawarte w niniejszym Podręczniku. Ad3) Współczynniki VAF dla oprogramowania wytwarzanego / modyfikowanego w ramach projektu są ustalane przez ARiMR i są zawarte w niniejszym Podręczniku. Ad4) Wymagania funkcjonalne użytkownika, z których wynika identyfikacja elementów modelu IFPUG są łącznym zbiorem zawierającym: wymagao funkcjonalnych użytkownika, które służyły wcześniej, jako podstawa dla opracowania AOM/AOP dla istniejącego oprogramowania, wymagao funkcjonalnych użytkownika określających danych projekt / modyfikację. Ad5) Zasady identyfikacji oraz szacowania elementów modelu IFPUG to zasady oryginalnej metody wraz z interpretacjami jej stosowania zawartymi w niniejszym dokumencie. Należy podkreślid, iż wspomniana wyżej zasada dla kroku 4 procedury szacowania oznacza, iż zbiór wymagao funkcjonalnych dla danego oprogramowania jest nadrzędny zarówno dla modelu IFPUG jak i dla modelu AOM/AOP. Oznacza to również, iż nie istnieje bezpośrednie powiązanie elementów modelu IFPUG oraz modelu AOM/AOP. Łącznikiem tych dwóch modeli są wymagania gdyż zarówno elementy modelu IFPUG jak i modelu AOM/AOP realizują konkretne wymagania ze zbioru wymagao funkcjonalnych użytkownika. Wymagania funkcjonalne użytkownika Istniejące oprogramowanie Projekt / modyfikacja

10 Model AOM/AOP Model IFPUG Powyższe oznacza, iż elementów modelu IFPUG nie należy wyprowadzad z istniejących elementów modelu AOM/AOP, ale wprost z ze zbioru wymaganiach funkcjonalnych użytkownika. Odstępstwem od powyższej reguły może byd sytuacja, gdy dla danego projektu istniejące oprogramowanie jest opisane wyłącznie poprzez model AOM/AOP. W takiej sytuacji, w ramach każdej modyfikacji oprogramowania w tym projekcie, wymagane jest odtworzenie nadrzędnego zbioru wymagao funkcjonalnych użytkownika. Z punktu widzenia szacowania, zbiór wymagao funkcjonalnych użytkownika powinien zawierad wymagania na takim poziomie szczegółowości by było możliwe zidentyfikowanie elementów modelu, IFPUG czyli w szczególności, ale nie tylko: 1) Wymagania powinny opisywad konkretne cele, jakie użytkownik chce osiągnąd przy pomocy oprogramowania aczkolwiek nie jest niezbędne wskazywanie sekwencji kroków interakcji z oprogramowaniem, jakie muszą byd przeprowadzone oraz reguł przetwarzania danych w tych krokach. 2) Wymagania powinny określad zakres danych, jakie ma przechowywad oprogramowanie aczkolwiek nie jest niezbędne wskazywanie typów, formatów, zasad walidacji i wyliczeo tych danych. 3) Wymagania powinny określad zakres danych wprowadzanych do systemu oraz wyprowadzanych do systemu przy realizacji określonych celów użytkownika, przy czym nie jest konieczne wskazywanie typów, formatów, zasad walidacji i wyliczeo tych danych. Powyższy minimalny zakres wymagao funkcjonalnych użytkownika jest zakresem na potrzeby szacowania metodą IFPUG. Nie wyklucza to jednak oczywiście innych potrzeb, dla których te wymagania powinny byd rozszerzone o dodatkowe elementy. Powyższy minimalny zakres wymagao funkcjonalnych użytkownika można określid również, jako taki opis wymagao, który zawiera minimum: zidentyfikowane przypadki użycia celu użytkownika, zidentyfikowane klasy modelu dziedziny (lub zbiór klas reprezentujących ten model), zidentyfikowane atrybuty klasy modelu dziedziny. Pojęcie zidentyfikowane oznacza tu, iż te elementy są nazwane aczkolwiek nie jest opisany sposób ich realizacji, wyliczania, formatu i zasad walidacji. METODA PF IFPUG ZASADY Metoda IFPUG definiuje następujące artefakty, jako elementy modelu IFPUG: Elementarny proces (EP Elementary Process) minimalna funkcja oprogramowania mająca znaczenie dla użytkownika, mogąca byd wykonana niezależnie i której realizacja pozostawia oprogramowanie w stanie stabilnym. Funkcja wejścia (EI External Input) elementarny proces przetwarzający dane przychodzące z zewnątrz granicy oprogramowania do jej wnętrza.

11 Funkcja wyjścia (EO External Output) - elementarny proces przetwarzający i wysyłający dane z wewnątrz granicy oprogramowania na jej zewnątrz. Funkcja zapytania (EQ External Inquiry) elementarny proces wysyłający dane z wewnątrz granicy oprogramowania na jej zewnątrz. Plik danych (FTR File Type Referenced) rozpoznawalny przez użytkownika zbiór logicznie powiązanych danych odczytywany lub zarządzany przez elementarne procesy. Wewnętrzny plik danych (ILF Internal Logical File) - wewnętrzny plik danych przechowywujący dane wewnątrz granicy oprogramowania. Zewnętrzny plik danych (EIF External Interface File) - zewnętrzny plik danych, przechowywane poza granicami szacowanego oprogramowania, do którego odwołują się elementarne procesy tego oprogramowania. Przykład: W przypadku, gdy oprogramowanie umożliwia rejestrowanie dokumentów kancelaryjnych to funkcja rejestracji nowego dokumentu będzie elementarnym procesem typu EI, funkcja prezentująca raport z zarejestrowanych dokumentów będzie elementarnym procesem typu EQ, funkcja prezentująca statystykę tempa rejestracji dokumentów będzie elementarnym procesem typu EO gdyż wylicza dodatkowe dane, nieprzechowywane w aplikacji; zbiór danych przechowywujący dane zarejestrowanych dokumentów będzie plikiem danych typu ILF a zbiór danych przechowywujący dane klientów organizacji (zarządzanym w ramach innego oprogramowania) będzie plikiem danych typu EIF wykorzystywanym celem identyfikacji nadawcy dokumentu. W celu wyznaczenia rozmiaru funkcjonalnego oprogramowania konieczne jest określenie dla definiującego to oprogramowanie zbioru wymagao funkcjonalnych wszystkich wyżej zdefiniowanych elementów modelu IFPUG tj. elementarnych procesów EI, EO i EQ oraz plików danych ILF i EIF. W celu wyznaczenia rozmiaru funkcjonalnego zmiany oprogramowania konieczne jest zidentyfikowanie - w istniejącym modelu IFPUG oprogramowania przed zmianą - tych elementów modelu IFPUG, które ulegną zmianie.

12 IDENTYFIKACJA MODELU DANYCH IFPUG Celem określenia plików danych, należy zidentyfikowad grupy logicznie powiązanych danych rozpoznawalnych przez użytkownika, jako realizujących jego wymagania. Dane od siebie zależne należy łączyd w niezależne pliki danych. Dane zależne to dane powiązane ze sobą relacją kompozycji, czyli: dane zależne istnieją wyłączenie, jeśli istnieją dane nadrzędne, usunięcie danych nadrzędnych powoduje usunięcie danych zależnych. Nie należy, jako plików danych traktowad: 1) Metadanych mających znaczenie wyłącznie dla technicznego opisu danych biznesowych. 2) Pojedynczo występujących obiektów posiadających małe ilości rzadko zmiennych atrybutów. 3) Danych statycznych rzadko zmienianych. 4) Domyślnych danych dla obiektów tworzonych przez aplikację. 5) Enumeracji dla atrybutów innych danych. 6) Definicji zakresów poprawności i formatów atrybutów dla innych danych. 7) Danych złączeniowych zawierających jedynie klucze obce czy indeksy definiujące relacje pomiędzy innymi danymi. Przykład: Istniejący na modelu dziedziny związek wiele do wielu pomiędzy klasą A i klasą B wymaga utworzenia w modelu relacyjnym tablicy złączeniowej T. Z punktu widzenia modelu danych IFPUG istnieją jednak dwa pliki danych: A oraz B. Tablica T jest daną techniczną i nie jest uwzględniania w szacowaniu aczkolwiek atrybuty wskazujące związek pomiędzy klasami A i B są elementami każdego z tych plików danych. Zidentyfikowane pliki danych należy zaklasyfikowad, jako pliki ILF, jeśli są to dane wewnątrz granic szacowanego oprogramowania lub jako pliki EIF, jeśli są to dane referencyjne poza granicami szacowanego oprogramowania. Przykład: Aplikacja do rejestracji dokumentów wpływających do organizacji opcjonalnie korzysta z systemu CRM celem identyfikacji nadawców. Dane podmiotów nadawców z systemu CRM, z punktu widzenia szacowania aplikacji do rejestracji dokumentów, są modelowane, jako plik danych EIF. Dla każdego pliku danych należy określid jego unikalne atrybuty (DET Data Element Type). Atrybut pliku danych to każdy rozpoznawalny przez użytkownika, unikalny atrybut pliku danych, który jest zarządzany, zapisywany, aktualizowany lub odczytywany w ramach elementarnych procesów szacowanego oprogramowania. Atrybutami są również atrybuty związków danego pliku danych z innymi plików danych, przy czym w zależności od nawigowalności tego związku, atrybut związku jest określany w jednym lub w obu powiązanych plikach danych. Mając określone atrybuty poszczególnych plików danych należy zidentyfikowad w ramach plików danych rekordy (RET Record Element Type). Rekord grupuje w ramach pliku danych atrybuty które występują w liczności innej niż 1:1 do pliku danych (inaczej mówiąc są one w relacji kompozycji). Domyślnie każdy plik danych ma jeden rekord. Przykład: Zbiór danych faktura to dane faktury plus lista pozycji faktury. Pozycja faktury jest elementem pliku danych Faktura i jest modelowana, jako rekord w tym pliku danych. Pozycja faktury nie istnieje bez faktury, usunięcie faktury usuwa wszystkie powiązanie z nią pozycje faktury. IDENTYFIKACJA MODELU FUNKCJONALNEGO IFPUG

13 Celem określenia elementarnych procesów należy zidentyfikowad minimalne niezależne funkcje oprogramowania mające znaczenie dla użytkownika oraz które są transakcjami tj. pozostawiają oprogramowanie w stabilnym stanie. Zidentyfikowane minimalne niezależne funkcje oprogramowania należy powiązad w postaci unikalnych elementarnych procesów, jeśli: wymagają tych samych atrybutów, wymagają tych samych plików danych, wymagają tej samej logiki przetwarzania danych. Przy czym w ramach jednego elementarnego procesu łączy się różne minimalne funkcje, które są tylko wariantami realizacji określonego celu użytkownika ze względu na warianty logiki przetwarzania lub warianty wykorzystania atrybutów lub plików danych. Przykład: System umożliwia rejestracje danych podmiotów, przy czym rejestrowane są zarówno podmioty, jako osoby fizyczne jak i prawne. Elementarny proces EI Rejestracja podmiotu obsługuje oba te przypadki a zbiór atrybutów tego procesu jest łącznym zbiorem wszystkich atrybutów osób prawnych i fizycznych. Zidentyfikowane elementarne procesy należy sklasyfikowad przypisując im jeden z trzech określonych przez metodę typów tj. EI, EO lub EQ. Elementarny proces jest procesem typu EI, jeśli: 1) Zawiera logikę przetwarzania walidującą dane wprowadzane w ramach tego procesu do systemu, lub 2) Jego podstawowym zadaniem jest zarządzanie (dodawanie, usuwanie, modyfikacja) jednym lub więcej plikami danych w ramach procesu, lub 3) Jego podstawowym zdaniem jest modyfikacja zachowania oprogramowania po zakooczeniu realizacji procesu (poprzez modyfikację określonych plików danych). Przykład: Funkcja rejestracji dokumentu kancelaryjnego jest procesem EI gdyż umożliwia wprowadzenie do oprogramowania danych rejestrowanego dokumentu. Elementarny proces jest procesem typu EO, jeśli jego podstawowym zadaniem jest prezentacja danych użytkownikowi z wykorzystaniem przynajmniej jednego ze sposobów przetwarzania danych: 1) Obliczeo matematycznych. 2) Aktualizacji pliku lub plików ILF. 3) Utworzenia prezentowanych danych. 4) Modyfikacja zachowania oprogramowania po zakooczeniu realizacji procesu (poprzez modyfikację określonych plików danych). Przykład: Funkcja utworzenia raportu z zarejestrowanych dokumentów kancelaryjnych jest procesem typu EO gdyż zawiera informacje o liczbie zarejestrowanych dokumentów z podziałem na stanowiska rejestracji. Elementarny proces jest procesem typu EQ, jeśli jego zadaniem jest prezentacja informacji i nie zawiera przetwarzania danych wskazanego dla procesów typu EO. Przykład: Funkcja wyszukiwania dokumentów kancelaryjnych Est procesem typu EQ gdyż prezentuje wyłącznie dane dokumentów zapisane w bazie. Dla każdego zidentyfikowanego i sklasyfikowanego elementarnego procesu należy następnie określid, z jakich plików danych ten proces korzysta (odczyt lub zapis) oraz jakie atrybuty są w ramach procesu wykorzystywane. Jako atrybuty wykorzystywane przez elementarny proces należy traktowad:

14 unikalne i rozpoznawalnych przez użytkownika atrybuty danych przekracza granicę systemu podczas realizacji procesu, jeden atrybut, jeśli elementarny proces może prezentowad użytkownikowi komunikaty (prosty błędy / potwierdzenia) związane z realizacją procesu niezależnie od liczby tych komunikatów, jeden atrybut na każda akcję, jaka skutkuje uruchomieniem innego elementarnego procesu niezależnie od liczby sposobów na uruchomienie tych akcji. Nie należy traktowad, jako atrybutów elementarnych procesów: opisów na formatach, nagłówków kolumn, nazw pól, znaczników wersji, znaczników typów, znaczników czasowych nie mających znaczenia biznesowego (tj. wpływającego na procesy biznesowe użytkownika), numerowania stron, wierszy, liczb porządkowych w tabelach, elementów nawigacyjnych interfejsu użytkownika, elementów wspomagających wprowadzanie danych na interfejsie użytkownika, atrybutów generowanych w ramach realizacji procesu, ale nie przekraczających granicy oprogramowania, atrybutów odczytywanych z plików danych nieprzekraczających granicy oprogramowania. Przykład: Raport z liczby zarejestrowanych dokumentów kancelaryjnych jest tworzony na zadany dzieo i prezentuje liczbę dokumentów zarejestrowanych w poszczególnych stanowiskach rejestracyjnych. Na raporcie jest też prezentowana wersja formularza raportu oraz godzina wygenerowania. Z punktu widzenia użytkownika te dwa ostatnie parametry są nieistotne - są to parametry techniczne dostawcy oprogramowania kancelaryjnego. Tym samym, jako atrybuty procesu zalicza się atrybut dnia, na jaki jest tworzony raport, liczbę raportów i identyfikacje stanowiska. Dodatkowo mogą byd również zliczone przycisk wykonania raportu na zadane parametry (jako realizacja akcji tego procesu) oraz ew. 1 DET dla komunikatu o błędnych parametrach.

15 WYLICZENIE ROZMIARU FUNKCJONALNEGO ELEMENTÓW MODELU IFPUG Rozmiar funkcjonalny plików danych jest wypadkową liczby atrybutów i rekordów w danym pliku. Rozmiar funkcjonalny elementarnych procesów jest wypadkową liczby atrybutów procesu i liczby wykorzystywanych plików danych. Dla każdego z typów artefaktów modelu to jest zdefiniowana odpowiednia tabela wyliczeniowa. ILF DET 1-19 DET DET > 50 RET 1 LOW (7) LOW (7) AVERAGE (10) RET 2 5 LOW (7) AVERAGE (10) HIGH (15) RET > 5 AVERAGE (10) HIGH (15) HIGH (15) EIF DET 1-19 DET DET > 50 RET 1 LOW (5) LOW (5) AVERAGE (7) RET 2 5 LOW (5) AVERAGE (7) HIGH (10) RET > 5 AVERAGE (7) HIGH (10) HIGH (10) EI DET 1 4 DET 5 15 DET > 15 FTR < 2 LOW (3) LOW (3) AVERAGE (4) FTR 2 LOW (3) AVERAGE (4) HIGH (6) FTR > 2 AVERAGE (4) HIGH (6) HIGH (6) EQ DET 1 5 DET 6 19 DET > 19 FTR < 2 LOW (3) LOW (3) AVERAGE (4) FTR 2 LOW (3) AVERAGE (4) HIGH (6) FTR > 2 AVERAGE (4) HIGH (6) HIGH (6) EO DET 1-5 DET 6-19 DET > 19 FTR < 2 LOW (4) LOW (4) AVERAGE (5) FTR 2 3 LOW (4) AVERAGE (5) HIGH (7) FTR > 3 AVERAGE (5) HIGH (7) HIGH (7) Suma rozmiarów funkcjonalnych wszystkich elementów modelu IFPUG jest rozmiarem oprogramowania w punktach funkcyjnych. Przykład: Plik danych ILF o 25 atrybutach i dwóch rekordach ma złożonośd 10 punktów funkcyjnych. Elementarny proces EQ o 3 atrybutach i jednym wykorzystywanym pliku FTR ma złożonośd 3 punkty funkcyjne. METODA PF IFPUG Z ROZSZERZENIEM OPRACOWANYM PRZEZ ORGANIZACJĘ NESMA W przypadku zmiany oprogramowania możliwe są trzy różne rodzaje zmian: dodanie nowej funkcjonalności, usunięcie istniejącej funkcjonalności, modyfikacja istniejącej funkcjonalności. W przypadku dodawania i usuwania funkcjonalności rozmiar funkcjonalny tych zmian wyznacza się, jako rozmiar dodawanych lub usuwanych elementów modelu IFPUG, przy czym w przypadku usuwanych elementów stosuje współczynnik wpływu Rozmiar funkcjonalny usuwanego elementu modelu jest iloczynem jego rozmiaru funkcjonalnego i podanego współczynnika wpływu. W przypadku modyfikacji istniejącej funkcjonalności stosuje się dodatkowe reguły opracowane przez organizację, NESMA we wspomnianym wcześniej dokumencie. WYLICZANIE ZMIAN MODELU DANYCH

16 Plik danych jest uznawany za zmieniony, jeśli są do niego dodane atrybuty, odjęte atrybuty, zmieniony jest typ atrybutu lub zmieniona jest struktura rekordów. Inną możliwą zmianą pliku danych jest zmiana jego typu (EIF / ILF). Celem wyliczenia rozmiaru zmiany pliku danych należy wyliczyd rozmiar funkcjonalny pliku danych po zmianie oraz wskazad liczbę zmienianych atrybutów. Mając te dane wylicza się procentowy wskaźnik zmiany. Ten wskaźnik służy do wyliczenia wskaźnika wpływu zmiany. Iloczyn wskaźnika wpływu zmiany oraz rozmiaru pliku po zmianie wyznacza rozmiar funkcjonalny zmiany pliku danych. Procentowy wskaźnik zmiany: ( liczba zmienionych atrybutów / liczba atrybutów przed zmianą) * 100% Wskaźnik wpływu wyznacza się w oparciu o poniższą tabelę: Procentowy wskaźnik zmiany p 30 % 30 % < p 60 % 60% < p 100% p >100% Wskaźnik wpływu W przypadku, gdy zmianie ulegnie typ pliku danych to wskaźnik wpływu dla tej modyfikacji ma wartośd W przypadku, gdy jednocześnie uległy zmianie atrybuty to, jako wskaźnik wpływu przyjmuje się wartośd większą spomiędzy wskaźnika wynikającego z modyfikacji typu oraz wskaźnika wynikającego ze zmian atrybutów. W przypadku, gdy dwa pliki danych są łączone w jeden to traktuje się to, jako usunięcie dwóch plików i dodanie jednego nowego. W przypadku, gdy istniejący plik jest dzielony to traktuje się to, jako usunięcie jednego pliku i dodanie dwóch nowych. Przykład: Plik danych ILF A posiada 15 atrybutów i jeden rekord. W ramach modyfikacji jest dodawanych kolejnych pięd a dodatkowo dla jednego istniejącego jest zmieniany typ danych. Złożonośd pliku przed modyfikacją to 7 PF. Procentowy wskaźnik zmiany to (6/15)*100% = 40%. Wskaźnik wpływu to Złożonośd pliku po modyfikacji to 10 PF. Złożonośd zmiany to 10 PF * 50% = 5 PF. WYLICZANIE ZMIAN MODELU FUNKCJI Elementarny proces jest uznawany za zmieniony, jeśli zachodzi jeden z poniższych warunków: jest dodany, ujęty lub zmodyfikowany atrybut elementarnego procesu, jest zmodyfikowany plik danych wykorzystywany przez elementarny proces, jest zmodyfikowany interfejs użytkownika lub format raportu, zmieniona jest logika przetwarzania danych w ramach elementarnego procesu. Celem wyliczenia rozmiaru zmiany elementarnego procesu należy wyliczyd rozmiar funkcjonalny procesu po zmianie oraz wskazad liczbę zmienianych atrybutów i plików danych. Mając te dane wylicza się procentowy wskaźnik zmiany. Ten wskaźnik służy do wyliczenia wskaźnika wpływu zmiany. Iloczyn wskaźnika wpływu zmiany oraz rozmiaru procesu po zmianie wyznacza rozmiar funkcjonalny zmiany elementarnego procesu. Procentowy wskaźnik zmiany atrybutów: ( liczba zmienionych atrybutów / liczba atrybutów przed zmianą) * 100% Procentowy wskaźnik zmiany plików: ( liczba zmienionych plików / liczba plików przed zmianą) * 100% Wskaźnik wpływu wyznacza się w oparciu o poniższą tabelę: Procentowy wskaźnik zmiany pa 60 % 60 % < pa 100 % pa >100% atrybutu Procentowy wskaźnik zmiany plików pp 30 %

17 30% < pp 60 % % < pp 100% pp >100% W przypadku, gdy zmiana dotyczy zmiany interfejsu użytkownika to wskaźnik wpływu dla takiej zmiany wynosi W przypadku, gdy zmiana dotyczy logiki przetwarzania to należy określid, które atrybuty i pliki danych są wykorzystywane w ramach zmianie logiki przetwarzania i liczba tych atrybutów / plików jest wykorzystywana do wyliczenia procentowego wskaźnika zmian. W przypadku podziałów / połączeo elementarnych procesów należy te zmiany traktowad, jako usuwanie starych i dodawanie nowych elementarnych procesów. Zmiana typu procesu wynika ze zmiany logiki / atrybutów i nie jest osobno wyliczana (jest to tylko klasyfikacja). Przykład: Elementarny proces E1 korzysta z pliku danych ILF1 i wykorzystuje 10 atrybutów. Ma złożonośd 3 PF. W wyniku zmiany, proces korzysta z dodatkowe pliku ILF2 oraz wykorzystuje kolejne dwa atrybuty. Procentowy wskaźnik zmiany atrybutów to 2/10 * 100% = 20%. Procentowy wskaźnik zmiany plików to ½ * 100% = 50%. Wskaźnik wpływu wynosi, zatem 0.5. Złożonośd procesu po zmianie to 4 PF. Złożonośd zmiany to 4 PF * 0.4 = 2PF. ZASADY STOSOWANIA WSPÓŁCZYNNIKA VAF Współczynnik VAF (Value Adjustment Factor) w założeniu twórców metody PF IFPUG ma odzwierciedlad złożonośd wymagao niefunkcjonalnych. Współczynnik ten jest konstruowany w oparci o 14 parametrów opisujących Globalną Charakterystykę Systemu (GSC, Global System Characteristic). Listę tych parametrów przedstawia poniższa tabela. Numer Nazwa Opis parametru GSC-1 Komunikacja Określa wagę wykorzystania przez aplikację różnych protokołów komunikacyjnych GSC-2 Przetwarzanie rozproszone Określa wagę wymiany danych pomiędzy różnymi komponentami aplikacji GSC-3 Wydajnośd Określa wagę wymagao dotyczących wydajności w projektowaniu aplikacji GSC-4 Infrastruktura Określa wagę wymagao dotyczących infrastruktury dla aplikacji GSC-5 Tempo transakcji Określa wagę tempa przetwarzania transakcji biznesowych GSC-6 Dane on-line Określa wagę on-line owego sposobu wprowadzania danych GSC-7 Ergonomia Określa wagę ergonomii interfejsu użytkownika GSC-8 Aktualizacje on-line Określa wagę wymagao odnośnie aktualizacji aplikacji i jej danych GSC-9 Złożone przetwarzanie Określa wagę złożoności algorytmów przetwarzania danych w aplikacji GSC-10 Ponowne użycie Określa wagę możliwości ponownego wykorzystania fragmentów aplikacji lub jej konfiguracji pod specyficzne zastosowania GSC-11 Instalacja Określa wagę złożoności procesu instalacji aplikacji GSC-12 Utrzymanie Określa wagę złożoności procesu utrzymania aplikacji GSC-13 Liczba lokalizacji Określa wagę dostępności aplikacji na różne platformy i liczbę potencjalnych instalacji GSC-14 Konfigurowalnośd Określa wagę wymagao odnośnie możliwości konfiguracji logiki przetwarzania aplikacji przez użytkownika

18 Dla każdego z powyższych parametrów określa się jego wartośd od 0 do 5 w oparciu o zasady opisane w oryginalnym podręczniku IFPUG. Wartośd VAF wyznacza się następująco: VAF = 0, x i=1..14 GSC-i. Skorygowana liczba punktów funkcyjnych IFPUG jest wyznaczana, jako iloczyn nieskorygowanej liczby punktów funkcyjnych i współczynnika VAF. W projektach ARiMR, o ile w danym projekcie jest wykorzystywany VAF, jest on wyznaczany w oparciu o normę ISO 9126 Quality of Service. Norma ta zakłada 6 kluczowych parametrów dotyczących skalowalnośd, dostępnośd i odtwarzalnośd systemu, czyli najistotniejsze elementy z punktu widzenia wymagao niefunkcjonalnych opisujących wydajnośd oraz jakośd funkcjonalności oprogramowania. Poniższa tabela zawiera opis parametrów normy ISO 9126 QoS: ID Kategoria Pod-kategoria Opis QoS-1A Funkcjonalnośd Interoperacyjnośd System IT współpracuje z innymi systemami IT QoS-1B Funkcjonalnośd Bezpieczeostwo System IT posiada mechanizmy ochrony funkcji i danych zarówno przed celowym jak i przypadkowym uszkodzeniem / utratą / udostępnieniem QoS-2A Niezawodnośd Dostępnośd System IT zapewnia dostępnośd przez określony poziom % czasu wykorzystywania. QoS-2B Niezawodnośd Odtwarzalnośd System IT zawiera mechanizmy odtworzenia po awarii. QoS-3A Wydajnośd Szybkośd działania System IT udostępnia funkcjonalnośd w określonych reżimach czasów reakcji i wykonywania. QoS-3B Wydajnośd Wykorzystanie zasobów System IT zawiera mechanizmy kontrolujące wykorzystanie zasobów infrastrukturalnych. QoS-4A Użytecznośd Zrozumiałośd System IT zawiera mechanizmy ułatwiające jego poznawanie i rozumienie przez użytkowników. QoS-5A Konserwowalnośd Zarządzalnośd System IT zawiera mechanizmy ułatwiające zarządzanie aplikacjami, funkcjami i danymi QoS-5B Konserwowalnośd Reużywalnośd Elementy Systemu IT mogą byd wykorzystane w innych systemach. QoS-6A Przenośnośd Zgodnośd System IT jest zgodny ze standardami technologicznymi i integracyjnymi QoS-6B Przenośnośd Instalowalnośd System IT zawiera mechanizmy ułatwiające jego instalowanie w określonych środowiskach. Poniższa tabela zawiera mapowanie GSC na QoS: GSC QoS GSC-1 Komunikacja QoS-1B Funkcjonalnośd : Bezpieczeostwo GSC-2 Przetwarzanie rozproszone QoS-1A Funkcjonalnośd : Interoperacyjnośd GSC-3 Wydajnośd QoS-3A Wydajnośd : Szybkośd działania GSC-4 Infrastruktura QoS-3B Wydajnośd : Wykorzystanie zasobów GSC-5 Tempo transakcji - Skalowalnośd (poza QoS)

19 System jest dostosowany do łatwego skalowania infrastruktury. GSC-6 Dane on-line QoS-2A Niezawodnośd : Dostępnośd GSC-7 Ergonomia QoS-4A Użytecznośd : Zrozumiałośd GSC-8 Aktualizacje on-line - Obsługa peak ów (poza QoS) System jest przystosowany do obsługi okresowych wzrostów obciążeo wynikających ze specyfiki obsługiwanych procesów biznesowych GSC-9 Złożone przetwarzanie - Algorytmy (poza QoS) Złożonośd algorytmów wynika z wymagao funickjonalnych GSC-10 Ponowne użycie QoS-5B Konserwowalnośd : Reużywalnośd GSC-11 Instalacja QoS-6B Przenośnośd : Instalowalnośd GSC-12 Utrzymanie QoS-2B Niezawodnośd : Odtwarzalnośd GSC-13 Liczba lokalizacji QoS-6A Przenośnośd : Zgodnośd GSC-14 Konfigurowalnośd QoS-5A Konserwowalnośd : Zarządzalnośd Tym samym dla systemów ARiMR wyznacza się najpierw parametry QoS a następnie, w oparciu o przedstawione powyżej mapowanie, wyznacza się współczynnik VAF. Należy podkreślid, iż powyższe mapowanie nie jest mapowaniem jedno odpowiada drugiemu, ale raczej jedno zastępuje drugie. Dla powyższej przedstawionych parametrów należy ekspercko określad ich wartośd w przedziale 0 5 gdzie 0 oznacza iż dany parametr nie ma znaczenia dla systemu (nie jest obsługiwany) a 5 oznacza iż dany parametr ma kluczowe znaczenie i jest w pełni obsługiwany. Przykład: System S1 zapewnia obywatelom dostęp read-only do danych i statusów spraw dla złożonych przez nich wniosków pomocowych. Dla systemu S1 VAF = * ( ) = 1.05 QoS System S1 Wartość GSC-1 QoS-1B Funkcjonalnośd : System S1 wymaga pełnego zabezpieczenia 3 Bezpieczeostwo autoryzacji, lecz nie wymaga pełnego zabezpieczenia utraty danych gdyż jest odtwarzany na podstawie systemu głównego. GSC-2 QoS-1A Funkcjonalnośd : System S1 współpracuje z systemem głównym 1 Interoperacyjnośd na zasadzie nocnych aktualizacji wsadowych. GSC-3 QoS-3A Wydajnośd : Szybkośd działania System S1 nie ma specjalnych wymogów wydajnościowych dane użytkownika powinny byd dla niego dostępne w czasie 10s od zgłoszenia potrzeby dostępu. 2 GSC-4 QoS-3B Wydajnośd : Wykorzystanie zasobów System S1 z racji ograniczeo infrastrukturalnych musi monitorowad liczbę otwartych sesji i kolejkowad zgłoszenia. System S1 nie musi monitorowad wykorzystania przestrzeni bazy danych. GSC-5 - Skalownośd (poza QoS) System S1 musi byd w pełni skalowalny. 5 GSC-6 QoS-2A Niezawodnośd : Dostępnośd System S1 musi byd dostępny 24/7 5 GSC-7 QoS-4A Użytecznośd : Zrozumiałośd System S1 musi byd łatwy do użycia dla 5 nieprzeszkolonych i niedoświadczonych użytkowników aplikacji internetowych GSC-8 - Obsługa peak ów (poza QoS) System S1 musi byd przygotowany pod kątem 5 większego zapotrzebowania na dostępnośd w okresie przygotowywania naliczeo. GSC-9 - Wymagania Funkcjonalne (poza Z wymagao funkcjonalnych nie wynika by 0 QoS) system S1 był złożony obliczeniowo GSC-10 QoS-5B Konserwowalnośd : System S1 nie ma wymagao związanych z re 1 Reużywalnośd używalnością jego elementów GSC-11 QoS-6B Przenośnośd : Instalowalnośd System S1 jest instalowany przez Wykonawcę 0 GSC-12 QoS-2B Niezawodnośd : Odtwarzalnośd System S1 ma mechanizmy automatycznego 5 odtworzenia po awarii GSC-13 QoS-6A Przenośnośd : Zgodnośd System S1 jest oparty o architekturę SOA i jest zgodny ze standardami interoperacyjności oraz 5 3

20 GSC-14 QoS-5A Konserwowalnośd : Zarządzalnośd pracy z przeglądarkami System S1 jest zarządzany przez Wykonawcę 0

21 PROCES SZACOWANIA ROZMIARU OPROGRAMOWANIA / ZMIANY OPROGRAMOWANIA ZASADY TWORZENIA I UTRZYMYWANIA MODELU ARTEFAKTÓW PF IFPUG Model IFPUG dla danego zbioru aplikacji zdefiniowanych dla danego projektu jest utrzymywany, jako jeden projekt EA. Każda aplikacja posiada własny model w ramach tego projektu. Struktura tego modelu powinna odzwierciedlad logiczny model funkcji i danych aplikacji. Pliku danych są modelowane, jako klasy ze stereotypem <<ILF>> lub <<EIF>>. Rekordy plików są modelowane, jako klasy w relacji kompozycji z klasą główną. Nazwa rekordu to <nazwa klas głównej>_<nazwa rekordu>. Relacje pomiędzy zbiorami danych są modelowane, jako asocjacje klas ze wskazaniem nawigowalności. Atrybuty plików są modelowane, jako atrybuty klas bez określania ich typów oraz opisów chyba, iż opis jest niezbędny by prawidłowo zidentyfikowad dany atrybut. Atrybuty związków pomiędzy plikami danych nie są modelowane dodatkowo są odzwierciedlone poprzez asocjacje klas reprezentujących pliki danych i ich rekordy. Jeśli plik danych EIF jest plikiem ILF w jednej z aplikacji to modeluje się go, jako klasę w relacji <<dependency>> do właściwego pliku, ILF, do którego interfejs dla aplikacji zewnętrznych symbolizuje dany plik EIF. Należy przy tym pamiętad, iż pliki EIF są zliczane, jako rozmiar funkcjonalny aplikacji, która z nich korzysta a nie tej, która je wystawia. Elementarne procesy są modelowane, jako przypadki użycia ze stereotypami <<EI>>,<< EQ>> oraz <<EO>>. Wykorzystanie plików danych przez elementarne procesy jest modelowane, jako relacja <<dependency>> do głównej klasy danego pliku danych. Liczbę atrybutów pliku danych (bez precyzowania, jakich) zapisuje się, jako licznośd związku po stronie pliku danych. Gdy dany elementarny proces wykorzystuje atrybuty inne niż w modelu plików danych to należy te atrybutu zdefiniowad w oddzielnej klasie ze stereotypem <<EP>> oraz nazwą odpowiadającą nazwie wykorzystującego ją procesu. Zasada powiązania i licznośd są analogiczne jak powyżej. W przypadku elementarnych procesów modelujących złożone procesy obliczeniowe dodatkowo oznacza się ich związek z elementarnymi procesami funkcjonalności w ramach, których są dostępne za pomocą relacji <<dependency>>. Dla tych procesów stosuje się też inne stereotyp: <<aeo>>. W przypadku elementarnych procesów modelujących niezależne funkcjonalności złożonych raportów dodatkowo oznacza się ich związek z elementarnymi procesami raportów w ramach, których są dostępne za pomocą relacji <<dependency>>. Dla tych procesów stosuje się też inny stereotyp: <<reo>>. W kontekście zmian: elementy modelu (EP/FTR) zmieniane mają status "Proposed", elementy modelu (EP/FTR) niezmieniane mają status "Implemented", element modelu (EP/FTR) ma oznaczoną liczbę zmienianych atrybutów jako "tagged value" o postaci: o IFPUG_ATT_D dla wskazania liczby dodawanych w zmianie atrybutów, o IFPUG_ATT_M dla wskazania liczby modyfikowanych w zmianie atrybutów, o IFPUG_ATT_U dla wskazania liczby usuwanych w zmianie atrybutów (atrybuty usunięte pozostają na modelu IFPUG dla danej zmiany). Dla modelu elementarnych procesów nie definiuje się aktorów. Na diagramach EP nie umieszcza się elementów FTR (tworzone są wyłącznie powiązania).

22 Każdy elementarny proces i plik danych posiada swój unikalny niezmienny identyfikator postaci xy-zzzz gdzie: x - kod Systemu Informatycznego ARiMR, y - kod podsystemu Systemu Informatycznego ARiMR, zzzz - unikalny numer elementu modelu.

23 Przykład: Rysunek 1 Model EP Rysunek 2 Model FTR ZASADY PREZENTACJI WYNIKÓW SZACOWANIA PF IFPUG W DOKUMENTACJI OFERTOWEJ W ramach przedstawienia wyników oszacowania w ofercie Wykonawca jest zobowiązany wskazad: dodawane elementy modelu IFPUG, usuwane elementy modelu IFPUG, modyfikowane elementy modelu IFPUG. Dla każdego wskazywanego elementu modelu musi byd podany jego numer, nazwa, wymaganie funkcjonalne, z którego wynika dany element, typ oraz ostateczny rozmiar funkcjonalny zmiany (w przypadku modyfikowanych elementów rozmiar po uwzględnieniu współczynników wpływu).

24 Na żądanie ARiMR Wykonawca jest zobowiązany przekazad model IFPUG w postaci projektów EA przed zmianą i po zmianie tj. z modelem IFPUG reprezentującym stan oprogramowania przed wprowadzeniem modyfikacji / ulepszenia oraz po modyfikacji / ulepszeniu.

25 PROCES WERYFIKACJI SZACOWANIA ARiMR weryfikuje oszacowanie IFPUG dostarczone przez Wykonawcę w oparciu wymagania, z których wynika oszacowanie oraz w oparciu o model IFPUG dostarczony przez Wykonawcę, jako projekt w narzędziu Enterprise Architect. Dostarczony model IFPUG musi spełniad wymagania formalne wskazane w niniejszym Podręczniku. Zarówno model plików danych jak i model elementarnych procesów muszą spełniad wszystkie reguły metody IFPUG wraz z rozszerzeniem NESMA oraz dodatkowe reguły zawarte w niniejszym Podręczniku. LISTA KONTROLA WERYFIKACJI MODELU DANYCH IFPUG. 1. Model spełnia wymogi formalne. 2. Pliki danych ILF zawierają dane wewnątrz granic oprogramowania. 3. Pliki danych EIF są poza granicami oprogramowania. 4. Istnieje przynajmniej jeden elementarny proces wykorzystujący dany plik danych. 5. Każdy plik danych zawiera logicznie spójny zbiór danych rozpoznawalny przez użytkownika i realizujący jego cele. 6. Każdy atrybut pliku danych jest unikalny i rozpoznawalny przez użytkownika. 7. Każdy rekord pliku danych poza podstawowym zawiera zbiór atrybutów w relacji 1:* w stosunku do podstawowych atrybutów pliku danych. 8. Wśród atrybutów pliku danych nie ma atrybutów technicznych oraz innych niespełniających reguł IFPUG. 9. Klucze obce są zamodelowane, jako ukierunkowane powiązania pomiędzy plikami danych. 10. Zidentyfikowany, jako zmieniony plik danych ma zmienione, dodane lub usunięte atrybuty lub zmieniony typ. 11. Zidentyfikowany, jako zmieniony atrybut ma zmieniony typ danych. 12. Zidentyfikowane, jako zmienione powiązanie ma zmienioną nawigowalnośd lub docelową klasę. LISTA KONTROLA WERYFIKACJI MODELU FUNKCJI IFPUG. 1. Model spełnia wymogi formalne. 2. Elementarne procesy są unikalne, znaczące dla użytkownika i realizują transakcje tj. pozostawiają oprogramowanie w stanie stabilnym. 3. Różne elementarne procesy nie są różnymi wariantami realizacji logiki, doboru danych, jednego procesu elementarnego realizującego określony cel użytkownika. 4. Każdy elementarny proces jest sklasyfikowany typem zgodny z głównym celem, jako realizacji wskazanym w tabeli poniżej. 5. Każdy elementarny proces zawiera przynajmniej jedną logikę przetwarzania wskazaną w tabeli poniżej. 6. Z każdego powiązanego pliku danych dany elementarny proces wykorzystuje przynajmniej jeden atrybut. 7. Dodatkowe atrybuty elementarnych procesów zamodelowane w klasach <<EP>> nie powielają atrybutów z plików danych, z którymi te procesy są powiązane. 8. Dodatkowe atrybuty elementarnych procesów są unikalne i znaczące dla użytkownika. 9. Dodatkowe atrybuty elementarnych procesów nie zawierają atrybutów związanych z nawigacją po interfejsie użytkownika, danymi statycznymi i opisami oraz innych niespełniających reguł IFPUG. 10. Zidentyfikowane, jako zmienione procesy mają zmienioną logikę przetwarzania, lub atrybuty lub zmienione są pliki danych, z których korzystają. 11. Zidentyfikowany, jako zmieniony atrybut elementarnego procesu ma zmieniony typ danych. Główne cele procesów w zależności od ich klasyfikacji:

Oszacowanie pracochłonności wykonania systemu metodą punktów funkcyjnych

Oszacowanie pracochłonności wykonania systemu metodą punktów funkcyjnych Oszacowanie pracochłonności wykonania systemu metodą punktów funkcyjnych Data sporządzenia: 29.11.2007 Przygotowana przez: Radosław Hęś, Krzysztof Fligiel 1 1. Wprowadzenie W dokumencie użyto następujących

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

Raport dotyczący przeprowadzonych zmian w aplikacji

Raport dotyczący przeprowadzonych zmian w aplikacji Łukasz Dobrodziej Warszawa, 8.01.2011 Jakub Madkowiak Raport dotyczący przeprowadzonych zmian w aplikacji Optymalizacja wydajnościowa Operacjami wykazującymi znaczący czas wykonywania się są grupowe operacje

Bardziej szczegółowo

Inżynierski Projekt Zespołowy

Inżynierski Projekt Zespołowy Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

Bardziej szczegółowo

Specyfikacja Wymagań. System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1

Specyfikacja Wymagań. System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1 Specyfikacja Wymagań System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1 1. Wymagania sprzętowe i środowiskowe 1.1. Wymagania podstawowe Nowy system ma być dostępny dla wszystkich pracowników

Bardziej szczegółowo

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika Prowadzący: Dr inż. Jacek Habel Instytut Technologii Maszyn i Automatyzacji Produkcji Zakład Projektowania Procesów

Bardziej szczegółowo

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa pliku Tom 6 Opis oprogramowania, Część 2 Generator danych

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Zasady Wykorzystywania Plików Cookies

Zasady Wykorzystywania Plików Cookies Zasady Wykorzystywania Plików Cookies Definicje i objaśnienia używanych pojęć Ilekroć w niniejszym zbiorze Zasad wykorzystywania plików Cookies pojawia się któreś z poniższych określeń, należy rozumieć

Bardziej szczegółowo

Zakres wymagań dotyczących Dokumentacji Systemu

Zakres wymagań dotyczących Dokumentacji Systemu Załącznik nr 2 do Umowy nr CUI/.../.../.../2014 z dnia r. Zakres wymagań dotyczących Dokumentacji Systemu 1. Uwagi i wymagania ogólne 1. Dokumentacja musi zostać dostarczona w wersji elektronicznej edytowalnej

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

Analiza punktów funkcyjnych Miara wielkość funkcjonalnej oprogramowania

Analiza punktów funkcyjnych Miara wielkość funkcjonalnej oprogramowania Analiza punktów funkcyjnych Miara wielkość funkcjonalnej oprogramowania Tomasz Koszlajda Instytut Informatyki Politechniki Poznańskiej Potrzeby określenia wielkości oprogramowania Dane wejściowe dla estymacji

Bardziej szczegółowo

Opis przedmiotu zamówienia

Opis przedmiotu zamówienia Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia Przedmiotem zamówienia jest usługa opracowania dokumentów standaryzujących tworzenie Elektronicznej Dokumentacji Medycznej wraz z aktualizacją transformaty

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

Podręcznik użytkownika Publikujący aplikacji Wykaz2

Podręcznik użytkownika Publikujący aplikacji Wykaz2 Podręcznik użytkownika Publikujący aplikacji Wykaz2 TiMSI Sp z o o ul Czapli 63, 02-781 Warszawa tel : +48 22 644 86 76, fax: +48 22 644 78 52 NIP: 951-19-39-800 Sąd Rejonowy dla mst Warszawy w Warszawie,

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Opis wymagań i program szkoleń dla użytkowników i administratorów

Opis wymagań i program szkoleń dla użytkowników i administratorów Załącznik nr 3 do OPZ Opis wymagań i program szkoleń dla użytkowników i administratorów Spis treści Wprowadzenie...2 1. Typ i zakres szkoleń...2 2. Grupy użytkowników...2 3. Warunki ogólne szkoleń...3

Bardziej szczegółowo

Część I Rozpoczęcie pracy z usługami Reporting Services

Część I Rozpoczęcie pracy z usługami Reporting Services Spis treści Podziękowania... xi Wprowadzenie... xiii Część I Rozpoczęcie pracy z usługami Reporting Services 1 Wprowadzenie do usług Reporting Services... 3 Platforma raportowania... 3 Cykl życia raportu...

Bardziej szczegółowo

INSTRUKCJA INSTALACJI APLIKACJI PROF- EAN 2

INSTRUKCJA INSTALACJI APLIKACJI PROF- EAN 2 INSTRUKCJA INSTALACJI APLIKACJI PROF- EAN 2 1. Instalacja programu PROF-EAN 2 Instalacje uruchamiamy poprzez plik:, wówczas kreator automatycznie poprowadzi nas przez proces instalacji. 2. Deklaracja instalacji

Bardziej szczegółowo

Spis treści: 1Wstęp...3 2Metody szacowania...3 3Wady metod opartych na jednostkach programowych...3 4Metoda punktów funkcyjnych (MPF)...

Spis treści: 1Wstęp...3 2Metody szacowania...3 3Wady metod opartych na jednostkach programowych...3 4Metoda punktów funkcyjnych (MPF)... Spis treści: 1Wstęp...3 2Metody szacowania...3 3Wady metod opartych na jednostkach programowych...3 4Metoda punktów funkcyjnych (MPF)...4 5Wstępne pojęcia dotyczące MPF...5 6Schemat liczenia punktów funkcyjnych...6

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl

enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl Spis treści Spis treści Moduł Produkcja Funkcjonalność Menu modułu Operacje wzorcowe

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ Załącznik nr 2 do umowy nr 11/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU APLIKACJI CENTRALNEJ Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania realizacją umowy

Bardziej szczegółowo

Metoda Punktów Funkcyjnych

Metoda Punktów Funkcyjnych Wrocław, 20.12.2002 Zarządzanie Projektem Informatycznym Metoda Punktów Funkcyjnych Spis treści: 1 Wstęp 3 2 Metody szacowania 3 3 Wady metod opartych na jednostkach programowych 3 4 Metoda punktów funkcyjnych

Bardziej szczegółowo

INTENSE BUSINESS INTELLIGENCE PLATFORM

INTENSE BUSINESS INTELLIGENCE PLATFORM 0 Business Intelligence w przedsiębiorstwie INTENSE BUSINESS INTELLIGENCE PLATFORM Zmiany w wersji Wersja 6.6 1 Spis treści Wstęp... 2 Nowości w wersji... 2 Wersjonowanie załączników... 2 Widoki list...

Bardziej szczegółowo

enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl

enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl enova365 Produkcja Oprogramowanie ERP do zarządzania. Wzmacnia firmę i rośnie wraz z nią. www.enova.pl, www.enova365.pl Spis treści Spis treści Moduł Produkcja Konfiguracja Definicja dokumentu Relacje

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Sekcja I: Instytucja zamawiająca/podmiot zamawiający

Sekcja I: Instytucja zamawiająca/podmiot zamawiający Unia Europejska Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, 2985 Luxembourg, Luksemburg Faks: +352 29 29 42 670 E-mail: ojs@publications.europa.eu Informacje i formularze

Bardziej szczegółowo

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch System Rozproszone Komunikator Dokumentacja Maciej Muszkowski Jakub Narloch Wymagania Zgodnie ze wstępnymi założeniami komunikator musi, realizowad następujące funkcje: 1. Jest oparty o model Peer2Peer,

Bardziej szczegółowo

Soneta Sp. z o.o. Standardowe kreatory CRM

Soneta Sp. z o.o. Standardowe kreatory CRM Soneta Sp. z o.o. Standardowe kreatory CRM Spis treści 1. Wstęp...2 2. Kreatory w enova CRM...2 3. Uruchomienie kreatora...3 4. Formularz kreatora Kampania z korespondencją...3 5. Formularz kreatora Nowy

Bardziej szczegółowo

Zapytanie ofertowe. zakup usługi doradczej z zakresu integracji systemu z istniejącym w firmie oprogramowaniem sztuk 1.

Zapytanie ofertowe. zakup usługi doradczej z zakresu integracji systemu z istniejącym w firmie oprogramowaniem sztuk 1. 101 Studio DTP Tomasz Tęgi i Spółka Sp. z o.o. ul. Ekonomiczna 30/36 93-426 Łódź Tel. +4842/250 70 92-94 Fax. +4842/250 70 95 NIP: 725-12-59-070 REGON: 471-35-84-10 Łódź, 10.02.2011 (miejsce, data) Zapytanie

Bardziej szczegółowo

Pytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia

Pytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia Warszawa, 11 kwietnia 2013 r. Dotyczy: postępowania prowadzonego w trybie przetargu nieograniczonego na Usługi wsparcia technicznego, utrzymania oraz rozwoju systemu Soprano, Phoenix oraz Register Plus

Bardziej szczegółowo

enova Systemowe Narzędzia Projektowe

enova Systemowe Narzędzia Projektowe enova Systemowe Narzędzia Projektowe Sebastian Wabnik Spis treści Opis rozwiązania...3 Dostęp do narzędzia...3 Wywoływanie narzędzia...4 Zakładka Logi czasu...4 SQL Stat...5 Zakładka Liczniki...7 Zakładka

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

CRM VISION FUNKCJE SYSTEMU

CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU CRM Vision to nowoczesne, bezpieczne oprogramowanie wspomagające zarządzanie firmą poprzez usprawnienie przepływu

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 09 grudnia 2014 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.3 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

UpSoft RCP wersja 1.0.50.22033

UpSoft RCP wersja 1.0.50.22033 UpSoft RCP wersja 1.0.50.22033 UpSoft RCP to moduł do programu Enova umożliwiający ewidencję i rozliczanie czasu pracy pracowników wg danych z rejestratorów czasu pracy. Ułatwia kontrolę pracowników (spóźnienia,

Bardziej szczegółowo

BMC Control-M Wybrane przypadki zastosowania

BMC Control-M Wybrane przypadki zastosowania Piotr Orlański Mariusz Gajewski CompFort Meridian Polska & BMC Software BMC Control-M Wybrane przypadki zastosowania Warszawa, 11 czerwca 2015 DISASTER RECOVERY Środowisko bankowe Problem: Zorganizowanie

Bardziej szczegółowo

Standard określania klasy systemu informatycznego resortu finansów

Standard określania klasy systemu informatycznego resortu finansów Dane dokumentu Nazwa Projektu: Kontrakt Konsolidacja i Centralizacja Systemów Celnych i Podatkowych Studium Projektowe Konsolidacji i Centralizacji Systemów Celnych i Podatkowych (SPKiCSCP) Numer wersji

Bardziej szczegółowo

ZAŁACZNIK NR 1D KARTA USŁUGI Utrzymanie Systemu Poczty Elektronicznej (USPE)

ZAŁACZNIK NR 1D KARTA USŁUGI Utrzymanie Systemu Poczty Elektronicznej (USPE) Załącznik nr 1D do Umowy z dnia.2014r. ZAŁACZNIK NR 1D KARTA USŁUGI Utrzymanie Systemu Poczty Elektronicznej (USPE) 1. INFORMACJE DOTYCZĄCE USŁUGI 1.1. CEL USŁUGI: W ramach Usługi Usługodawca zobowiązany

Bardziej szczegółowo

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.2 Cyfrowe udostępnienie zasobów kultury Programu Operacyjnego Polska Cyfrowa na lata 2014-2020 Typ projektu Cyfrowe udostępnienie zasobów kultury

Bardziej szczegółowo

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie architektury systemu rozproszonego Jarosław Kuchta Zagadnienia Typy architektury systemu Rozproszone przetwarzanie obiektowe Problemy globalizacji Problemy ochrony Projektowanie architektury

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Zasoby enova CRM Konfiguracja uprawnień

Zasoby enova CRM Konfiguracja uprawnień Zasoby enova CRM Konfiguracja uprawnień Soneta Sp z o.o. ul. Wadowicka 8a, wejście B 31-415 Kraków tel./fax +48 (12) 261 36 41 http://www.enova.pl e-mail: crm@enova.pl Spis treści 1. Wstęp... 2 2. Opis

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się

Bardziej szczegółowo

Założenia i stan realizacji projektu epuap2

Założenia i stan realizacji projektu epuap2 Założenia i stan realizacji projektu epuap2 Michał Bukowski Analityk epuap Serock, 28 października 2009 r. Agenda 1. Projekt epuap - cele i zakres. 2. Zrealizowane zadania w ramach epuap. 3. Projekt epuap2

Bardziej szczegółowo

PLAN REALIZACJI MATERIAŁU NAUCZANIA Z INFORMATYKI II. Uczeń umie: Świadomie stosować się do zasad regulaminów (P).

PLAN REALIZACJI MATERIAŁU NAUCZANIA Z INFORMATYKI II. Uczeń umie: Świadomie stosować się do zasad regulaminów (P). PLAN REALIZACJI MATERIAŁU NAUCZANIA Z INFORMATYKI II DZIAŁ I: KOMPUTER W ŻYCIU CZŁOWIEKA. 1. Lekcja organizacyjna. Zapoznanie uczniów z wymaganiami edukacyjnymi i PSP. 2. Przykłady zastosowań komputerów

Bardziej szczegółowo

Zintegrowany System Informatyczny (ZSI)

Zintegrowany System Informatyczny (ZSI) Zintegrowany System Informatyczny (ZSI) ZSI MARKETING Modułowo zorganizowany system informatyczny, obsługujący wszystkie sfery działalności przedsiębiorstwa PLANOWANIE ZAOPATRZENIE TECHNICZNE PRZYGOTOWANIE

Bardziej szczegółowo

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem.

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem. Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.1 Cyfrowe udostępnianie informacji sektora publicznego (ISP) ze źródeł administracyjnych oraz zasobów nauki Programu Operacyjnego Polska Cyfrowa

Bardziej szczegółowo

Oprogramowanie systemu B2B zakup licencji na oprogramowanie umożliwiające zarządzanie informacjami o produktach:

Oprogramowanie systemu B2B zakup licencji na oprogramowanie umożliwiające zarządzanie informacjami o produktach: ZAŁĄCZNIK NR 1 Dodatkowe informacje dotyczące systemu informatycznego B2B - zakres prac. Opracowanie systemu informatycznego (wykonanie, instalacja i konfiguracja / wdrożenie oraz usługi szkoleniowe) System

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS. Krok po kroku

Monitoring procesów z wykorzystaniem systemu ADONIS. Krok po kroku z wykorzystaniem systemu ADONIS Krok po kroku BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.5 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Aleksander Galisz. Gf aktura 1.0. Podręcznik użytkownika 2011-07-19

Aleksander Galisz. Gf aktura 1.0. Podręcznik użytkownika 2011-07-19 Aleksander Galisz Gf aktura 1.0 Podręcznik użytkownika 2011-07-19 1 Spis treści 1. Wymagania systemowe... 4 2. Instalacja... 4 2.1. Instalacja.NET Framework 3.5 SP1... 4 2.2. Instalacja programu Wkhtmltopdf...

Bardziej szczegółowo

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce Kielce, dnia 27.02.2012 roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / 39 25-344 Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży

Bardziej szczegółowo

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Systemy baz danych w zarządzaniu przedsiębiorstwem W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Proces zarządzania danymi Zarządzanie danymi obejmuje czynności: gromadzenie

Bardziej szczegółowo

Podręcznik użytkownika Obieg dokumentów

Podręcznik użytkownika Obieg dokumentów Podręcznik użytkownika Obieg dokumentów Opracowany na potrzeby wdrożenia dla Akademii Wychowania Fizycznego im. Eugeniusza Piaseckiego w Poznaniu W ramach realizacji projektu: Uczelnia jutra wdrożenie

Bardziej szczegółowo

Projektowani Systemów Inf.

Projektowani Systemów Inf. Projektowani Systemów Inf. Wykład VII Bezpieczeństwo Copyrights by Arkadiusz Rzucidło 1 Bezpieczeństwo Bezpieczeństwo związane z danymi Konstrukcja magazynów danych Mechanizmy zapisu i modyfikacji danych

Bardziej szczegółowo

Nowe funkcje w programie Forte Finanse i Księgowość

Nowe funkcje w programie Forte Finanse i Księgowość Forte Finanse i Księgowość 1 / 11 Nowe funkcje w programie Forte Finanse i Księgowość Spis treści : Korzyści z zakupu nowej wersji 2 Forte Finanse i Księgowość w wersji 2011.b 3 Nowe wzory deklaracji VAT

Bardziej szczegółowo

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej

Bardziej szczegółowo

Import danych z plików Excel. (pracownicy, limity urlopowe i inne)

Import danych z plików Excel. (pracownicy, limity urlopowe i inne) Import danych z plików Excel (pracownicy, limity urlopowe i inne) 1. Wstęp BeeOffice umożliwia import z plików Excel kilku rodzajów danych, najczęściej wykorzystywanych podczas tworzenia nowego systemu

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

Załącznik nr 1. Automatyczny rozrachunek zleceń w częściach. Specyfikacja założeń. str. 1 11.06.2012

Załącznik nr 1. Automatyczny rozrachunek zleceń w częściach. Specyfikacja założeń. str. 1 11.06.2012 Załącznik nr 1 Specyfikacja założeń 11.06.2012 str. 1 Spis treści Wstęp... 3 Założenia funkcjonalne... 4 I. Proces optymalizacji... 4 II. Warunki determinujące rozrachunek w częściach... 5 III. Obsługa

Bardziej szczegółowo

Import zleceń / Integracja klienta K-Ex

Import zleceń / Integracja klienta K-Ex Import zleceń / Integracja klienta K-Ex 1 1 Integracja systemów Klient K-Ex jako sposobem zwiększenia wydajności tworzenia wysyłki 1.1 Import przesyłek na podstawie pliku CSV Wprowadzenie danych na temat

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

Podstawowe zagadnienia z zakresu baz danych

Podstawowe zagadnienia z zakresu baz danych Podstawowe zagadnienia z zakresu baz danych Jednym z najważniejszych współczesnych zastosowań komputerów we wszelkich dziedzinach życia jest gromadzenie, wyszukiwanie i udostępnianie informacji. Specjalizowane

Bardziej szczegółowo

Portal Personelu Medycznego. 2010 Global Services Sp. z o.o.

Portal Personelu Medycznego. 2010 Global Services Sp. z o.o. Portal Personelu Medycznego 2 Portal Personelu Medycznego Spis treści Rozdział I Wprowadzenie 3 Rozdział II Konfiguracja 4 Rozdział III Aktywacja 5 Rozdział IV Opis aplikacji 7 Rozdział V Obsługa okien

Bardziej szczegółowo

Nowe funkcje w programie Symfonia Finanse i Księgowość

Nowe funkcje w programie Symfonia Finanse i Księgowość Symfonia Finanse i Księgowość 1 / 11 Nowe funkcje w programie Symfonia Finanse i Księgowość Spis treści : Korzyści z zakupu nowej wersji 2 Symfonia Finanse i Księgowość w wersji 2011.1.b 3 Nowe wzory deklaracji

Bardziej szczegółowo

Lokalna kopia bioinformatycznego serwera obliczeniowego jako wysokowydajne środowisko obliczeniowe

Lokalna kopia bioinformatycznego serwera obliczeniowego jako wysokowydajne środowisko obliczeniowe Lokalna kopia bioinformatycznego serwera obliczeniowego jako wysokowydajne środowisko obliczeniowe Dokument wizji Autorzy: Łukasz Kempny, Tomasz Sikora, Tomasz Rokita, Robert Ostrowski, Zbigniew Polek,

Bardziej szczegółowo

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Rozkład wymagający

Bardziej szczegółowo

Ekran główny lista formularzy

Ekran główny lista formularzy Administracja modułem formularzy dynamicznych Konfigurator formularzy dynamicznych Funkcjonalność konfiguratora formularzy dynamicznych pozwala administratorowi systemu na stworzenie formularza, w którym

Bardziej szczegółowo

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I Rozkład zgodny

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Czy chmura może być bezpiecznym backupem? Ryzyka systemowe i prawne. Jarosław Żeliński analityk biznesowy, projektant systemów Agenda Definicja usługi backup i cloud computing Architektura systemu z backupem

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

WYJAŚNIENIA ZAMAWIAJĄCEGO DOTYCZĄCE TREŚCI SIWZ

WYJAŚNIENIA ZAMAWIAJĄCEGO DOTYCZĄCE TREŚCI SIWZ Warszawa, dn. 17 lipca 2015 r. WYJAŚNIENIA ZAMAWIAJĄCEGO DOTYCZĄCE TREŚCI SIWZ dot. Postępowania o udzielenie zamówienia na Dostawę oprogramowania na potrzeby projektu Poprawa dostępności i jakości usług

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach OPIS WYMGŃ FUNKCJONLNO-TECHNICZNYCH dla zamówienia: Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach 2015-2016 Przedmiot zamówienia Przedmiotem zamówienia jest usługa

Bardziej szczegółowo

Wszystkie parametry pracy serwera konfigurujemy w poszczególnych zakładkach aplikacji, podzielonych wg zakresu funkcjonalnego.

Wszystkie parametry pracy serwera konfigurujemy w poszczególnych zakładkach aplikacji, podzielonych wg zakresu funkcjonalnego. Sz@rk Server - konfigurowanie systemu Sz@rk Server jest serwerem aplikacji z wydzieloną logiką biznesową, pracującym w architekturze opartej o usługi (SOA). Dane pomiędzy serwerem i klientami przesyłane

Bardziej szczegółowo

SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND. Dokumentacja projektu. Danilo Lakovic. Joanna Duda. Piotr Leżoń. Mateusz Pytel

SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND. Dokumentacja projektu. Danilo Lakovic. Joanna Duda. Piotr Leżoń. Mateusz Pytel SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND Dokumentacja projektu Danilo Lakovic Joanna Duda Piotr Leżoń Mateusz Pytel 1. Wstęp 1.1. Cel dokumentu Poniższy dokument ma na celu przybliżenie użytkownikowi

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC.

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC. 1 Moduł OPC Moduł OPC pozwala na komunikację z serwerami OPC pracującymi w oparciu o model DA (Data Access). Dzięki niemu można odczytać stan obiektów OPC (zmiennych zdefiniowanych w programie PLC), a

Bardziej szczegółowo

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Dr inż. Jacek WARCHULSKI Dr inż. Marcin WARCHULSKI Mgr inż. Witold BUŻANTOWICZ Wojskowa Akademia Techniczna SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Streszczenie: W referacie przedstawiono możliwości

Bardziej szczegółowo

Audyt oprogramowania systemu B2B oprogramowanie umożliwiające zarządzanie informacjami o produktach:

Audyt oprogramowania systemu B2B oprogramowanie umożliwiające zarządzanie informacjami o produktach: ZAŁĄCZNIK NR 1 Dodatkowe informacje dotyczące audytu systemu informatycznego B2B - zakres prac. Audyt oprogramowania (testy akceptacyjne i bezpieczeństwa) systemu informatycznego System B2B automatyzujący

Bardziej szczegółowo

Spis treści. 1 Moduł RFID (APA) 3

Spis treści. 1 Moduł RFID (APA) 3 Spis treści 1 Moduł RFID (APA) 3 1.1 Konfigurowanie Modułu RFID..................... 3 1.1.1 Lista elementów Modułu RFID................. 3 1.1.2 Konfiguracja Modułu RFID (APA)............... 4 1.1.2.1

Bardziej szczegółowo

Sekcja I: Instytucja zamawiająca/podmiot zamawiający

Sekcja I: Instytucja zamawiająca/podmiot zamawiający Unia Europejska Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, 2985 Luxembourg, Luksemburg Faks: +352 29 29 42 670 E-mail: ojs@publications.europa.eu Informacje i formularze

Bardziej szczegółowo