Plan testów dla systemu USOSweb 2.0
|
|
- Fabian Matusiak
- 7 lat temu
- Przeglądów:
Transkrypt
1 Plan testów dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 31 maja
2 Spis treści 1 Wprowadzenie Cel Zakres Definicje Omówienie reszty dokumentu Harmonogram testów Pierwsza iteracja Druga iteracja Zakres testów Testy funkcjonalności Testy integracji Testy wydajności Testy obciążeniowe Testy wytrzymałościowe Testy objętościowe Testy bezpieczeństwa Testy konfiguracji Testy odporności Testy łatwości użycia Testy dostępności Proces testowania Testy regresywne Testy jednostkowe Testy integracji z USOSem Potrzebne zasoby Zasoby sprzętowe Zasoby ludzkie Oprogramowanie Zarzadzanie błędami Dzienniki błędów Raporty Klasyfikacja błędów Procedury postępowania Ryzyko i zależności 9 8 Historia zmian 9 2
3 1 Wprowadzenie 1.1 Cel Celem tego dokumentu jest wprowadzenie czytelnika w plan oraz proces testów systemu USO- SWeb 2.0, a także umożliwienie mu zrozumienia metod postępowania w razie błędów. Dodatkowo w dokumencie umieszczony został harmonogram dwóch iteracji testów. 1.2 Zakres W dokumencie szczegółowo zostały rozpisane dwie iteracje testów systemu USOSWeb 2.0. Ponadto dokładniej scharakteryzowane są też konkretne typy testów oraz metody testowania. Omówione zostały także potrzebne do testów zasoby, możliwe związane z testami ryzyko oraz podstawy zarządzania błędami w projekcie. 1.3 Definicje USOS Uniwersytecki System Obsługi Studiów, USOSweb webowy interfejs do USOSa, dający dostęp do zasobów studentom i pracownikom naukowym wydziału System system, którego ten dokument dotyczy USOSweb Omówienie reszty dokumentu Kolejne częsci dokumentu omawiają szczegółowo następujące zagadnienia: Sekcja 2 - Harmonogram testów (wydzielone zostały dwie iteracje). Sekcja 3 - Szczegółowe opisanie znaczenia poszczególnych testów oraz sposobu i momentu ich wykonywania. Sekcja 4 - Zawiera opis metod testowania systemu. Sekcja 5 - Omówienie niezbędnych do procesu testowania zasobów ludzkich, sprzętowych i oprogramowaina. Sekcja 6 - Omówienie metod postępowania w razie błędów wykrytych w systemie. Sekcja 7 - Opisanie ryzyka oraz zależności związanego z testami. 3
4 2 Harmonogram testów 2.1 Pierwsza iteracja Testy w pierwszej iteracji odbędą się w nasępujących terminach: 1. Testy integracyjne Testy systemowe Testy obciążeniowe Łączny czas trwania testów: , 11 dni roboczych. 2.2 Druga iteracja Testy w drugiej iteracji odbędą się w nasępujących terminach: 1. Testy integracyjne Testy systemowe Testy ociążeniowe Łączny czas trwania testów: , 10 dni roboczych. 3 Zakres testów 3.1 Testy funkcjonalności Testowanie funkcjonalności obejmuje: Testowanie typu czarna skrzynka - będą tworzone przez osobę odpowiedzialną za testowanie w projekcie na podstawie specyfikacji. Bedą one wykorzystywane zarówno w testowaniu jednostkowym jak i testowaniu integracji. Testowanie typu biała skrzynka - testy wykorzystują znajomość sposobu implementacji i umożliwiają sprawdzenie poprawności większej ilości ścieżek w systemie. Testy tego typu będą tworzone przez osobę piszącą daną funkcję i będą wykorzystowane w testowaniu jednostkowym 3.2 Testy integracji Testowanie integracji umożliwi sprawdzenie bezbłędności komunikacji między modułami i zapewnienie poprawnego przepływu danych. Testy te są połączone z testowaniem funkcjonalości w podejściu czarnej skrzynki. Testy integracyjne będą wykonywane zgodnie z podejściem bottom-up. 4
5 3.3 Testy wydajności Testy te sprawdzą spełnienie założeń wydajnościowych nałożonych na System USOSweb 2.0 w dokumencie Wizja. Częściowe testy bedą wykonywane po zakończeniu każdej z iteracji, co umożliwi szybkie znajdowanie nieefektywnych partii systemu i ich szybkie poprawienie. Testy będą nagrywane i automatyzowane przy użyciu narzędzia JMeter. 3.4 Testy obciażeniowe Testy obciążeniowe umożliwią weryfikację zachowanie systemu podczas jednoczesnej obsługi wiele użytkowników. W szczegóności nastąpi testowanie jednoczesnego pobierania przez wiele osób plików. Testy obciążeniowe zostaną wykonane podczas fazy testowania. 3.5 Testy wytrzymałościowe Testy wytrzymałościowe symulują zachowanie Systemu w długich okresach czasu. Testy te umożliwiają także przetestowanie większej ilości ścieżek w systemie. Zostaną one przeprowadzone przez nagranie testów i ich ciągłe wykonywanie przez oprogramowanie testujące (JMeter). 3.6 Testy objętościowe Testy objętościowe umożliwią sprawdzenie zachowania systemu podczas przechowywanie dużej ilości danych - w szczególności granicznej liczby plików, etykiet i kont studenckich. Testy te wykonane zostaną podczas fazy testowania, po zakończeniu fazy implementacji. 3.7 Testy bezpieczeństwa Testy bezpieczeństwa obejmują sprawdzenie bezpieczeństwa przesyłania, przechowywania danych i podatności na popularne ataki (DOS, DDOS, SQL injection), jak również testy zakresów danych do jakich ma dostęp użytkownik. W szczególności, czy użytkownik nie może odczytywać danych lub wywoływać funkcji, do których nie ma uprawnień. Testy te zostaną wykonany po zakończeniu każdej z iteracji. Jeżeli system zostanie integrowany z USOSem może być koniecznie przeprowadzenie dodatkowych testów bezpieczeństwa przez firmę zewnętrzną. 3.8 Testy konfiguracji Testy konfiguracji pozwolą na sprawdzenie działania Systemu pod różnimy konfiguracjami sprzętowymi. Zostaną one zrealizowane poprzez wykonywanie testów funkcjonalności na różnych konfiguracjach sprzętowych. Test konfiguracji interfejsu będzie ponadto obejmował sprawdzenie zgodności kodu HTML ze standardem W3. 5
6 3.9 Testy odporności Ponieważ system USOSweb 2.0 ma współpracować z system USOS niezbędne jest wykonanie testów odporności, dzięki którym możliwe będzie zbadanie zachowania Systemu podczas awarii sprzętowych. Zbadane zostanie zachowanie systemów podczas symulowanych awarii dysku, pamięci a także wyłączenia systemów podczas przebywania systemów w każdym ze stanów, w których następuje aktualizacja przechowywanych danych Testy łatwości użycia Testy zostaną przeprowadzone przy użyciu metody hallway testing polegającej na wyborze kilku osób nie związanych z projektem, reprezentujących jednak grupę docelową - studentów, i obserwacji jak realizują przygotowany scenariusz postępowania. Mierzony będzie czas i poprawność wykonania zadania. Testy te zostaną wykonane po zakończeniu fazy implementacji i po wykonaniu głównej części pozostałych testów. Ponieważ dotyczą one jedynie interfejsu i dokumentacji użytkownika poprawianie błędów jest ułatwione Testy dostępności Testy dostępności zostaną przeprowadzone, jeśli zostanie uzyskana zgoda na integrację systemu z USOSem. Testy dostępności dotyczą jedynie interfejsu Systemu, więc ryzyko związane z poprawianiem błędów jest zminimalizowane. Testy te mają na cele sprawdzenie, czy korzystanie z systemu nie jest utrudnione dla osób niepełnosprawnych. 4 Proces testowania 4.1 Testy regresywne Testy regresywne będą przeprowadzane, bo każdej dużej zmianie w systemie. Jednak z powodu długiego czasu testowanie będą ograniczone jedynie do testów jednostkowych zmienianego modułu i krótkich testów integracji ( smoke testing ) 4.2 Testy jednostkowe Testy jednostkowe będą automatyzowane przy użyciu JUnit. 4.3 Testy integracji z USOSem Testy te dotyczą jedynie modułu Komunikacja z USOSem. Ponieważ moduł ten jest kluczowy dla funkcjonowanie systemu USOSweb 2.0 konieczne jest gruntowne przetestowanie zarówno pod kątem zapewnienia bezpieczeństwa jak i poprawności. Testy tego modułu będą poprzedzały testy pozostałych części systemu. Do czasu gruntowanego przetestowania tego modułu podczas testów koniecznie będzie wykorzystywanie mock objects. 6
7 5 Potrzebne zasoby 5.1 Zasoby sprzętowe Nazwa zasobu Ilość Szczegółowy opis Komputer osobisty 3 Dwa komputery z systemami operacyjnymi Microsoft Windows (Vista i XP), jeden komputer z systemem Linux Ubuntu Łącze internetowe 1 W celu przeprowadzenia miarodajnych testów potrzebne będzie łącze o przepustowości 1Mbit/s, w razie potrzeby sprzętowo limitowane. 5.2 Zasoby ludzkie Nazwa zasobu Ilość Szczegółowy opis Kierownik testów 1 Ma za zadanie zaprojektować przebieg testów, rozdzielić obowiązki, a następnie nadzorować ich przebieg. Projektant testów 1 Jego zadaniem będzie projektowanie poszczególnych testów zależnie od ich określonego celu. Testerzy wewnętrzni 2 Są to członkowie zespołu, ich zadaniem będzie przeprowadzanie testów oraz analizowanie ich wyników. Testerzy zewnętrzni W ostatniej fazie testów zostaną zaproszeni w celu wykrycia wszelkich błędów. Powinni posiadać dostęp do własnego spzętu. Analizą wyników ich testów zajmą się testerzy wewnętrzni. 5.3 Oprogramowanie Nazwa zasobu Ilość Szczegółowy opis JUnit 1 Testy oprogramowania i jego poszczególnych funkcji JMeter 1 Testy obciążeniowe. Przeglądarki Internetowe 5+ Zostaną wykorzystane w celu sprawdzenia kompatybilności z conajmniej pięcioma najpopularniejszymi przeglądarkami na rynku. 7
8 6 Zarzadzanie błędami 6.1 Dzienniki błędów W celu umożliwienia kontroli nad projektem zostaną narzucone następujące zasady postępowania odnośnie komponentów systemu. Dla każdej ważniejszej i odrębnej części projektu (czyli takiej, dla której można będzie wyróżniać kolejne mikro-wydania, na przykład moduł lub pliki źródłowe reprezentujące pewną charakterystyczną funkcjonalność) prowadzone mają być dzienniki zmian, poprawek, modyfikacji planowanych w następnym miko-wydaniu oraz błędów (jeżeli takowe zostały znalezione). Dokumenty te powinny przyjąć format popularnych change-logów. Ponadto przy każdym wpisie powinno widnieć nazwisko autora/ów (jeżeli nie wynika to w sposób oczywisty z przydziału prac). Change-logi powinny być przechowywane w repozytorium SVN w katalogu jednoznacznie wskazującym, jakiej części systemu dotyczą. 6.2 Raporty Wymagane jest, aby osoby pracujące nad większa częścią systemu (reprezentującą pewną ogólniejszą, spójną funkcjonalność), co pewien okres czasu pod kontrolą jednej z tych osób pisały raport zmian i błędów (nie jest ściśle narzucone jaki okres czasu, jednak chcemy, aby każdy większy postęp był uwzględniony). Raporty ważniejszych i bliższych klientowi komponentów mają mieć lepszą oprawę wizualną (możliwe, że zostaną one udostępnione klientowi lub odbędzie się konferencja). Ogólnie, raporty mają być generowane od skali mikro (w postaci changelogów) do makro (w postaci atrakcyjnych wizualnie prezentacji). 6.3 Klasyfikacja błędów Klasyfikacja błędów wygląda następująco: Drobne błędy: Błędy możliwe do naprawienia indywidualnie przez niewielką liczbę programistów. Nie wymagające zmiań w komponentach wyższych warstw. Jeżel sytacja tego nie wymaga, to błędy te mogą zostać naprawione po ukończeniu bieżących prac. Błędy integracyjne: Niezgodnosć poszczególnych komponentów oprogramowania na poziomie procedur i definicji. Błędy te powinny być naprawiane tuż po wykryciu, aby nie tworzyć dalszego rozspójnienia. Błędy technologiczne: Błędy wynikające z wad użytych technologii lub ich niezrozumienia. Reakcja na nie wymaga przemyślenia i nie powinna być gwałtowna. Błędy wydajnościowe: Wydajność systemu jest poniżej założonych wartości. Również w tym przypadku postępowanie nie powinno być gwałtowne. Błędy projektowe: Błędy w projekcie prowadzące do trudnej do naprawienia utraty integralności systemu. Wymagają jak najszybszej reakcji w celu ich usunięcia i umożliwienia dalszych prac. 8
9 Ponadto mogą wystąpić również inne błędy nie uwzględnione w powyższej klasyfikacji. 6.4 Procedury postępowania W przypadku drobnych błędów wystarczy po ich naprawieniu uwzględnić to w change-logach. W przypadku błędów integracyjnych, jeżeli są łatwe do naprawienia można postąpić tak jak wyżej. Inaczej należy wprowadzić modyfikacje do projektu wraz z architektami komponentów. Błędy technologiczne mogą wymagać większego wkładu niż poprzednie kategorie błędów. W tym przypadku po omówieniu problemu z menadżerami zostaje wydane rozporządzenie do głębszego poznania technologii (wymagać to będzie dodatkowego czasu) lub ograniczenia funkcjonalności. Menadżerowie powinni ponadto próbować skontaktować się z dostawcami technologii i uzyskać od nich dodatkowe informacji. Zakładamy jednak, że projektanci systemu wygrali technologię na tyle dobrze, że przedsięwzięcie się nie załamie. Błędy projektowe powinny być rozwiązywane drogą dyskusji trójstronnej (menadżerowie, projektanci oraz programiści). W ostateczności możliwe jest rozpoczęcie części prac od początku, zwiększenie kosztów lub znaczne ograniczenie funkcjonalności. 7 Ryzyko i zależności 7.1 Ryzyka Ryzyka które mogą wystąpić w trakcie testów: Choroba/Nieobecność członka zespołu Braki w umiejętnościach obsługi oprogramowania testowego Błędy w kodzie uniemożliwiające pełne testy Trudności ze znalezieniem testerów zewnętrznych Problemy natury sprzętowej (brak dostępu, awarie) 7.2 Zależności Testy zależne są od następujących czynników: Członkowie zespołu - aktywność, umiejętności wymagane do testów Testerzy zewnętrzni - ich aktywność oraz podejście do testów Sprzęt - jego sprawność Kod - jego przejrzystość w wypadku poważnych błedów 9
10 8 Historia zmian $Log: 27 V 2007: Utworzenie dokumentu. 28 V 2007: Wstępne wersje rozdziałów 3 i V 2007: Harmonogram, ryzyka, zasoby. $ 10
Rubik s Manager - Plan testów
Rubik s Manager - Plan testów Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 27 maja 2007 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoIO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2
Bardziej szczegółowoTestowanie oprogramowania. Piotr Ciskowski
Testowanie oprogramowania Piotr Ciskowski TESTOWANIE testowanie o proces eksperymentalnego badania programu lub jego komponentu o próbne wykonanie w znanych warunkach o rejestrowanie wyników o ocena właściwości
Bardziej szczegółowoPlan Testów Systemu SOS
Plan Testów Systemu SOS Marcin Suszczewicz Michał Woźniak Krzysztof Kostałkowicz Piotr Kuśka 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 4 1.1 Cel tego dokumentu................................. 4 1.2
Bardziej szczegółowoIO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoTestowanie oprogramowania
Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój
Bardziej szczegółowoZespół: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP Plan testów
Zespół: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak Projekt SZOP Plan testów Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoPlan testów. Robert Dyczkowski, Piotr Findeisen, Filip Grzdkowski. 4 czerwca 2006
Robert Dyczkowski, Piotr Findeisen, Filip Grzdkowski 4 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel dokumentu................................... 3 1.2 Oczekiwania....................................
Bardziej szczegółowoGalileo - encyklopedia internetowa Plan testów
Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................
Bardziej szczegółowoZałącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2
Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja
Bardziej szczegółowoRozdział 5: Zarządzanie testowaniem. Pytanie 1
Pytanie 1 Dlaczego niezależne testowanie jest ważne: A) Niezależne testowanie jest w zasadzie tańsze niż testowanie własnej pracy B) Niezależne testowanie jest bardziej efektywne w znajdywaniu defektów
Bardziej szczegółowoTopór Światowida Plan testów
Topór Światowida Plan testów Maciej Pawlisz Łukasz Polak Oskar Skibski Jakub Światły 5 czerwca 2007r. 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoKonwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008
Konwerter Plan testów Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008 1 Spis treści 1 Wprowadzenie 3 1.1 Cel........................................ 3 1.2 Zamierzeni odbiorcy
Bardziej szczegółowoTestujemy dedykowanymi zasobami (ang. agile testers)
Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania
Bardziej szczegółowoOverlord - Plan testów
Overlord - Plan testów Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 5 czerwca 2006 Spis treści 1 Wprowadzenie 2 1.1 Cel tego dokumentu................................. 2 1.2 Cele systemu testów................................
Bardziej szczegółowoDlaczego testowanie jest ważne?
Testowanie Dlaczego testowanie jest ważne? Oprogramowanie które nie działa poprawnie może doprowadzić do: straty czasu, pieniędzy utraty reputacji uszkodzeń ciała a nawet śmierci Definicja błędu Oprogramowanie
Bardziej szczegółowoPlan testów do Internetowego Serwisu Oferowania i Wyszukiwania Usług Transportowych
Plan testów do Internetowego Serwisu Oferowania i Wyszukiwania Usług Transportowych Michał Lewowski, Piotr Skowron, Michał Matczuk, Piotr Wygocki 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................
Bardziej szczegółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany
Bardziej szczegółowoUsługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Bardziej szczegółowoZasady 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ółowoSzablon 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ółowoUsługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
Bardziej szczegółowoFuzzing OWASP 14.01.2010. The OWASP Foundation http://www.owasp.org. Piotr Łaskawiec J2EE Developer/Pentester
Fuzzing Piotr Łaskawiec J2EE Developer/Pentester 14.01.2010 Metrosoft (www.metrosoft.com) piotr.laskawiec@gmail.com Copyright The Foundation Permission is granted to copy, distribute and/or modify this
Bardziej szczegółowoNajwyżej ocenione raporty dla Mr Buggy 4
Najwyżej ocenione raporty dla Mr Buggy 4 Uwagi Komisji: 1. Żaden z raportów nie otrzymał maksymalnej liczby punktów. 2. Poniżej prezentowane są oryginalne wersje raportów z usuniętymi danymi mogącymi identyfikować
Bardziej szczegółowoWeb 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ółowoTestowanie i walidacja oprogramowania
i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ
ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ 1. PRZEDMIOT ZAMÓWIENIA Przedmiotem zamówienia jest dostarczenie i wdrożenie systemu informatycznego dalej Platforma zakupowa
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoSoftware Architecture Document dla systemu USOSweb 2.0. Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt
Software Architecture Document dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 17 maja 2007 Spis treści 1 Wprowadzenie 4 1.1 Cel..........................................
Bardziej szczegółowoSLA ORAZ ZASADY ŚWIADCZENIA WSPARCIA I HELPDESK. Wykonawca zobowiązuje się do świadczenia Usług Wsparcia i Helpdesk w odniesieniu do Systemu.
SLA ORAZ ZASADY ŚWIADCZENIA WSPARCIA I HELPDESK Wykonawca zobowiązuje się do świadczenia Usług Wsparcia i Helpdesk w odniesieniu do Systemu. 1. ZAKRES USŁUG Nazwa Usługi Krótki opis Usuwanie Błędów Usuwanie
Bardziej szczegółowoSzkolenie: Testowanie wydajności (Performance Testing)
Szkolenie: Testowanie wydajności (Performance Testing) Testy niefunkcjonalne aplikacji to nieodłączna część pracy dobrego testera. Do tego typu testów zaliczamy między innymi taką właściwość systemu jak
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoKwestionariusz dotyczący działania systemów teleinformatycznych wykorzystywanych do realizacji zadań zleconych z zakresu administracji rządowej
Zał. nr 2 do zawiadomienia o kontroli Kwestionariusz dotyczący działania teleinformatycznych wykorzystywanych do realizacji zadań zleconych z zakresu administracji rządowej Poz. Obszar / Zagadnienie Podstawa
Bardziej szczegółowoMaciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
Bardziej szczegółowoRAPORT KOŃCOWY PROJEKTU
RAPORT KOŃCOWY PROJEKTU Temat: Wieloplatformowy program do obsługi faktur Adresat: dr inż. Jacek Kołodziej Wykonawcy: Daniel Krysiak Przemysław Szpunar Grzegorz Śmierzchalski Spis Treści 1. Charakterystyka
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoNiniejszy załącznik składa się z 5 ponumerowanych stron
ZAŁĄCZNIK NR 10 DO SIWZ PROCEDURA TESTOWANIA W PROJEKCIE E-ZDROWIE DLA MAZOWSZA NA DOSTAWY I WDROŻENIE EDM, SSI Niniejszy załącznik składa się z 5 ponumerowanych stron Warszawa, dnia 14.01.2015 r. Strona
Bardziej szczegółowoPROCEDURA 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ółowoRFP. Wymagania dla projektu. sklepu internetowego B2C dla firmy Oplot
RFP Wymagania dla projektu sklepu internetowego B2C dla firmy Oplot CEL DOKUMENTU Celem niniejszego dokumentu jest przedstawienie wymagań technicznych i funkcjonalnych wobec realizacji projektu budowy
Bardziej szczegółowoSzczegółowy opis przedmiotu zamówienia
Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja
Bardziej szczegółowoSDP systemu SOS. Marcin Suszczewicz Michał Woźniak Krzysztof Kostałkowicz Piotr Kuśka. 6 czerwca 2006
SDP systemu SOS Marcin Suszczewicz Michał Woźniak Krzysztof Kostałkowicz Piotr Kuśka 6 czerwca 2006 1 Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................
Bardziej szczegółowoZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.
ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego
Bardziej szczegółowoPrzypadki użycia produktu USOSweb 2.0. Karol Sobczak Adam Radziwończyk-Syta Marcin Koziński Grzegorz Paszt
Przypadki użycia produktu USOSweb 2.0 Karol Sobczak Adam Radziwończyk-Syta Marcin Koziński Grzegorz Paszt 22 marca 2007 1 Wprowadzenie 1.1 Cel Celem tego dokumentu jest zaznajomienie czytelnika z zagadnieniem
Bardziej szczegółowoPROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem
PROJEKTOWANIE określenie wymagań specyfikowanie projektowanie kodowanie implementacja testowanie produkt konserwacja Faza strategiczna Analiza Dokumentacja Instalacja PROJEKT most pomiędzy specyfikowaniem
Bardziej szczegółowoTestowanie oprogramowania. Testowanie oprogramowania 1/34
Testowanie oprogramowania Testowanie oprogramowania 1/34 Testowanie oprogramowania 2/34 Cele testowania testowanie polega na uruchamianiu oprogramowania w celu wykrycia błędów, dobry test to taki, który
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE Definicja ITQB Testowanie integracyjne (integration testing) wykonywane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami
Bardziej szczegółowoPraktyka testowania dla początkujących testerów
Praktyka testowania dla początkujących testerów Warsztaty stanowią 100% praktykę testowania i skupiają się zwłaszcza na tych aspektach, które przydatne są w codziennej pracy testera. Przeznaczone są dla
Bardziej szczegółowoIO - Plan przedsięwzięcia
IO - Plan przedsięwzięcia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Wprowadzenie 3 2.1 Cele................................ 3 2.2 Budżet...............................
Bardziej szczegółowoSzczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:
Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko
Bardziej szczegółowoProjekt 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ółowoZapytanie ofertowe 13-09-2013
Zapytanie ofertowe W związku z realizacją projektu współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Działania 8.2 Programu Operacyjnego Innowacyjna Gospodarka 2007-2013,
Bardziej szczegółowoInżynieria oprogramowania (Software Engineering)
Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania
Bardziej szczegółowoProgramowanie zespołowe
Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof
Bardziej szczegółowoSekcja 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ółowoDokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor
Koszalin, 15.06.2012 r. Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Zespół projektowy: Daniel Czyczyn-Egird Wojciech Gołuchowski Michał Durkowski Kamil Gawroński Prowadzący: Dr inż.
Bardziej szczegółowo1. Definicja pojęć Celem opisania warunków świadczenia usług gwarancji jakości Systemu i Asysty Powdrożeniowej definiuje się następujące pojęcia:
WARUNKI GWARANCJI JAKOŚCI I ASYSTY POWDROŻENIOWEJ 1. Definicja pojęć Celem opisania warunków świadczenia usług gwarancji jakości Systemu i Asysty Powdrożeniowej definiuje się następujące pojęcia: ASYSTA
Bardziej szczegółowoSzczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna
Bardziej szczegółowoOverlord - Software Development Plan
Overlord - Software Development Plan Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 5 czerwca 2006 Spis treści 0.1 Cel.......................................... 4 0.2 Zakres........................................
Bardziej szczegółowoOPIS PRZEDMIOTU ZAMÓWIENIA w postępowaniu pn.:
E/004/17 Załącznik A do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA w postępowaniu pn.: Abonament, obsługa oraz wsparcie techniczne systemu SAP Pakiet A Zakup usługi SAP Enterprise Support (abonament) 1. PRZEDMIOT
Bardziej szczegółowoTester oprogramowania 2014/15 Tematy prac dyplomowych
Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven
Bardziej szczegółowoJakość w procesie wytwarzania oprogramowania
Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu
Bardziej szczegółowoOpis Przedmiotu Zamówienia na przeprowadzenie testów bezpieczeństwa systemu wspomagania nadzoru archiwalnego e-nadzór
S t r o n a ǀ 1 z 5 Załącznik nr 1 do zapytania ofertowego Opis Przedmiotu Zamówienia na przeprowadzenie testów bezpieczeństwa systemu wspomagania nadzoru archiwalnego e-nadzór I. Definicje. 1. Dostawca
Bardziej szczegółowoTESTOWANIE APLIKACJI KORPORACYJNYCH
TESTOWANIE APLIKACJI KORPORACYJNYCH Autor: inż. Ewa ZYGA Promotor: dr inż. Marek MIŁOSZ 1. Rola przeprowadzania testów w procesie wytwarzania oprogramowania Po co testować? Odpowiedź jest prosta. Aby znaleźć
Bardziej szczegółowoPorównanie metod i technik testowania oprogramowania. Damian Ryś Maja Wojnarowska
Porównanie metod i technik testowania oprogramowania Damian Ryś Maja Wojnarowska Testy oprogramowania Testowanie oprogramowania jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów
Bardziej szczegółowoMetodyka projektowania komputerowych systemów sterowania
Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania
Bardziej szczegółowoWarunki świadczenia Asysty Technicznej
Załącznik nr 5do siwz Warunki świadczenia Asysty Technicznej 1. Wymagany minimalny okres świadczenia usługi Asysty Technicznej wynosi 24 miesiące. 2. Definicje: Aplikacja Administrator techniczny Awaria
Bardziej szczegółowoNazwa Projektu. Plan testów. Wersja N.NN
Nazwa Projektu Plan testów Wersja N.NN Projekt realizowany jest w ramach Programu e-cło współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna
Bardziej szczegółowoCASE STUDIES TEST FACTORY
CASE STUDIES TEST FACTORY Wiodący niemiecki bank inwestycyjny 01. Wsparcie klienta przez wysoko wykwalifikowany zespół analityków testowych oraz inżynierów automatyzacji testów Bankowość Wdrożenie nowego
Bardziej szczegółowoZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.
ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących
Bardziej szczegółowoktórego nie stosuje się przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych na:
GŁÓWNY URZĄD GEODEZJI I KARTOGRAFII Warszawa, 2 października 2015 r. DEPARTAMENT NADZORU, KONTROLI I ORGANIZACJI SŁUŻBY GEODEZYJNEJ I KARTOGRAFICZNEJ NG-KiSZ.2611.6.2015 Do wszystkich Wykonawców Dotyczy:
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja wymagań projektu. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoWykład 7. Projektowanie kodu oprogramowania
Wykład 7 Projektowanie kodu oprogramowania Treść wykładu cykl życiowy oprogramowania zagadnienia inżynierii oprogramowania tworzenie oprogramowania z gotowych elementów tworzenie niezawodnego oprogramowania
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków
Bardziej szczegółowoTestowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl
Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:
Bardziej szczegółowoStrategia testów mająca doprowadzić do osiągnięcia pożądanych celów
Dokumentacja testowa. Plan testów [ang. Test Plan] Plan testów jest jednym z podstawowych dokumentów w procesie testowym. Przedstawiamy wzór planu testów. testerzy.pl Zapraszamy do dyskusji o planie testów
Bardziej szczegółowoGrzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat
Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych
Bardziej szczegółowoVoicer. SPIKON Aplikacja Voicer V100
Voicer SPIKON Aplikacja Voicer V100 SPIKON Voicer Aplikacja Voicer w platformie SPIKON dedykowana jest przede wszystkim konsultantom kampanii wirtualnego Call Center. Dając łatwy dostęp do najważniejszych
Bardziej szczegółowoSzczegółowy opis przedmiotu zamówienia:
Załącznik nr 1 do SIWZ Szczegółowy opis przedmiotu zamówienia: I. Opracowanie polityki i procedur bezpieczeństwa danych medycznych. Zamawiający oczekuje opracowania Systemu zarządzania bezpieczeństwem
Bardziej szczegółowoCałościowe podejście do testowania automatycznego dla programistów. (TDD, BDD, Spec. by Example, wzorce, narzędzia)
Program szkolenia: Całościowe podejście do testowania automatycznego dla programistów Ruby (TDD, BDD, Spec. by Example, wzorce, narzędzia) Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania:
Bardziej szczegółowoTestowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia
Program szkolenia: Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Testowanie aplikacji mobilnych na
Bardziej szczegółowoModyfikacja i Aktualizacja Oprogramowania
Modyfikacja i Aktualizacja Oprogramowania Załącznik nr 4 do Umowy 1. W ramach udzielonej gwarancji i rękojmi Wykonawca zapewni prawidłowe (nieograniczone czasowo i funkcjonalnie) działanie Oprogramowania.
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoTesty poziom po poziomie
poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.
Bardziej szczegółowoTworzenie aplikacji Web Alicja Zwiewka. Page 1
Tworzenie aplikacji Web Alicja Zwiewka Page 1 Co to są web-aplikacje? Aplikacja internetowa (ang. web application) program komputerowy, który pracuje na serwerze i komunikuje się poprzez sieć komputerową
Bardziej szczegółowoKoncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source
Koncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source Dr inż. Michał Bednarczyk Uniwersytet Warmińsko-Mazurski w Olsztynie Wydział Geodezji i Gospodarki Przestrzennej Katedra Geodezji
Bardziej szczegółowoOpis Przedmiotu Zamówienia
Załącznik nr 1 do SIWZ/ załącznik nr 1 do umowy OP/UP/099/2011 Opis Przedmiotu Zamówienia 1. Przedmiot zamówienia 1.1. Przedmiotem zamówienia jest świadczenie usług konsultancko-developerskich dla systemu
Bardziej szczegółowoZAPYTANIE OFERTOWE. Wdrożenie systemu B2B w celu automatyzacji procesów biznesowych zachodzącymi między Wnioskodawcą a partnerami biznesowymi
Wrocław, 28 sierpnia 2014 r. ZAPYTANIE OFERTOWE KIEZA MARCIN MARCIN KIEZA PRO - CHEMIA PPH z siedzibą w Marcinkowicach przy ulicy Letnia 8a (55-200, Oława I) realizując projekt pt. Wdrożenie systemu B2B
Bardziej szczegółowoWrocław, dnia 21 maja 2015 r. Wszyscy, którzy pobrali SIWZ
Wrocław, dnia 21 maja 2015 r. Wszyscy, którzy pobrali SIWZ dotyczy: przetargu nieograniczonego na dostawę sprzętu komputerowego dla potrzeb Miejskiego Ośrodka Pomocy Społecznej. CPV 30213100-6, 30232100-5,
Bardziej szczegółowoOpis 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ółowoAudyt 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ółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoSoftVig Systemy Informatyczne Sp. z o.o. Szczecin , ul. Cyfrowa 4
SoftVig Systemy Informatyczne Sp. z o.o. Szczecin 71-441, ul. Cyfrowa 4 Centrala : (091) 350-89-20 Hotline aplikacji : (091) 350-89-26 e-mail : office@softvig.pl Fax : (091) 350-89-30 Dział handlowy :
Bardziej szczegółowoDwuwymiarowy sposób na podróbki > 34
TEMAT NUMERU I Bezpieczeństwo WIELE WYMIARÓW BEZPIECZEŃSTWA I zapobieganie zanieczyszczeniom krzyżowym I walka z fałszowaniem leków I walidacja rozwiązań chmurowych Maszyny rozwoju > 20 Dwuwymiarowy sposób
Bardziej szczegółowoStudia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW
01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO
Bardziej szczegółowoGłówne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)
Extreme programming Główne założenia XP Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Praktyki Planowanie: Planowanie releasu Planowanie iteracji
Bardziej szczegółowoBiorąc udział w projekcie, możesz wybrać jedną z 8 bezpłatnych ścieżek egzaminacyjnych:
Egzaminy na plus Stres na minus! Zdawaj bezpłatne egzaminy Microsoft, Linux, C++ z nami i zadbaj o swoją karierę. Oferujemy Ci pierwsze certyfikaty zawodowe w Twojej przyszłej karierze, które idealnie
Bardziej szczegółowo[1/15] Chmury w Internecie. Wady i zalety przechowywania plików w chmurze
Chmury w Internecie Nota Materiał powstał w ramach realizacji projektu e-kompetencje bez barier dofinansowanego z Programu Operacyjnego Polska Cyfrowa działanie 3.1 Działania szkoleniowe na rzecz rozwoju
Bardziej szczegółowoZarządzanie testowaniem wspierane narzędziem HP Quality Center
Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe
Bardziej szczegółowo