Opis realizacji dla czterech zespołów (4 przypadki użycia)

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "Opis realizacji dla czterech zespołów (4 przypadki użycia)"

Transkrypt

1 Projektowanie oprogramowania Termin zajęć: czwartek, sala L2.6, C , Na podstawie materiału ze strony Przebieg realizacji projektu (tabela 1) Nr tygodnia Opis realizacji dla czterech zespołów (4 przypadki użycia) Sprint Spotkanie Uwagi dotyczące realizacji Zespoły składające się z 4-6 studentów studentów- przystąpienie do kolejnego Daily Scrum po zaliczeniu poprzedzającego 1 1 Sprint planning meeting (90 min) Zajęcia organizacyjne ( podział na grupy, przydzielenie ról projektowych, uzyskanie dostępu do wymaganych narzędzi) Sprint Backlog - Opracowanie modelu biznesowego systemu Wypożyczalni sprzętu sportowego (grupa ) oraz systemu ProjectPortfolio (grupa ) udział wszystkich grup projektowych. Każda grupa projektowa otrzymuje ogólny opis procesów biznesowych, ale opracowuje dokładnie wybrany fragment opisu biznesowego Sprint Backlog - zdefiniowanie wymagań funkcjonalnych i niefunkcjonalnych udział wszystkich grup projektowych. Każda grupa dokładnie opracuje część wymagań funkcjonalnych wynikających z otrzymanego fragmentu opisu świata rzeczywistego Definicja PU (przypadku użycia): opis słowny wg standardowego formularza scenariusz należy wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). Każda grupa opracowuje przypadki użycia Liczba punktów (do oceny) 3-5 Zadania kierownika zespołów (Scrum Master)

2 2 Daily Scrum 3 Daily Scrum 4 Daily Scrum jako specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach. Podczas 1-tygodnia wynik prac umieszczane są w repozytorium java,net i są być oceniane przez prowadzących zajęcia Przedstawienie wyników prac z 1 tygodnia Projekt PU (wersja początkowa): diagram klas, diagramy sekwencji, diagramy aktywności diagramy stanów raport wygenerowanie dokumentacji, zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych(zalecane) Podczas 2-tygodnia wyniki prac umieszczane są w repozytorium java,net i są być oceniane przez prowadzących zajęcia Przedstawienie wyników prac z 2 tygodnia Projekt PU (wersja końcowa): diagram klas, diagramy sekwencji, diagramy aktywności diagramy stanów integracja raportów wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane). Podczas 3-tygodnia wyniki prac umieszczane są w wykonanego modelu do implementacji Implementacja1 PU (warstwa biznesowa): kod warstwy biznesowej na podstawie modelu wykonanego w tygodniach 1-3, koncepcja i kod testów jednostkowych i integracyjnych wykonanych za pomocą JUnit usuwanie błędów 3-5 Integrowanie projektów PU opracowanych przez diagramu przypadków użycia, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 4-10 Integrowanie projektów PU opracowanych przez diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 3-5 Włączenie się do zespołów wykonawców i wspomaganie prac.

3 5 Daily Scrum pomiar metryk oprogramowania za pomocą narzędzia CKJM ewentualna refaktoryzacja kodu w celu poprawy nieprawidłowych wartości metryk (w szczególności RFC, LCOM3) powtórzenie testów jednostkowych w przypadku refaktoryzacji kodu Podczas 4-tygodnia wyniki prac umieszczane są w wykonanego oprogramowanie na podstawie modelu wykonanego w 1-3 tygodniach Implementacja2 PU (warstwa prezentacji i klienta): opracowanie wspólnego szablonu tworzonych formularzy, ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client), koncepcja i kod testów akceptacyjnych (Selenium lub ręcznych) Podczas 5-tygodnia wyniki prac umieszczane są w wykonanej implementacji do integracji przez wydzielony zespół 4-10 Kontrola przyjętego standardu formularzy, 6 2 Scenariusz dla trzech zespołów Scenariusz dla jednego zespołu Sprint review meeting & Sprint planning meeting (90 min) Wszystkie grupy Rozbudowa diagramu PU (Sprint Backlog): planowanie nowych PU, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU. Rozdział nowych PU do 3 grup wykonawców Definicja PU (przypadku użycia): opis słowny wg standardowego formularza scenariusz należy wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). Każda grupa opracowuje przypadki użycia 3-5 Integracja 4 projektów typu EE (wg podanego tutorialu), dostarczonych po zakończeniu 5 tygodnia etap 1-y Ocena 3-5

4 7 Daily Scrum jako specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach. Podczas 6-tygodnia wynik prac umieszczane są w repozytorium java,net i są oceniane przez prowadzących zajęcia Przedstawienie wyników prac z 6 tygodnia Projekt PU (wersja końcowa): diagram klas, diagramy sekwencji, diagramy aktywności diagramy stanów integracja raportów wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane). Podczas 7-tygodnia wyniki prac umieszczane są w repozytorium java,net i mogą być oceniane przez prowadzących zajęcia 8 Przedstawienie wyników prac z 7 tygodnia Projekt PU (wersja końcowa): diagram klas (integracja przez Scrum Master diagramów klas z 7 tygodnia) diagramy sekwencji, diagramy aktywności diagramy stanów integracja raportów wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane). Podczas 8-tygodnia wyniki prac umieszczane są w wykonanego modelu do implementacji 9 Daily Scrum Implementacja1 PU (warstwa biznesowa) rozwój oprogramowania wykonanego w 1-ym sprincie i zintegrowanego przez zespół czwarty w tygodniu 7: kod warstwy biznesowej na podstawie modelu z 6-8 tygodnia koncepcja i kod testów jednostkowych i 3-5 Integrowanie PU opracowanych przez diagramu PU 4-10 Integrowanie projektów PU opracowanych przez diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu 3-5 Włączenie się do zespołów wykonawców i wspomaganie prac Integracja 4 projektów typu EE (wg podanego tutorialu) etap 2-i Wykonanie warstwy integracji opartej na technologii JPA etap 1-y Wykonanie warstwy integracji opartej na technologii JPA etap 2-i

5 10 Daily Scrum 11 3 Sprint review meeting & Sprint planning meeting (90 min) integracyjnych wykonanych za pomocą JUnit usuwanie błędów pomiar metryk oprogramowania za pomocą narzędzia CKJM ewentualna refaktoryzacja kodu w celu poprawy nieprawidłowych wartości metryk (w szczególności RFC, LCOM3) powtórzenie testów jednostkowych w przypadku refakatoryzacji Podczas 9-tygodnia wyniki prac umieszczane są w Włączenie się do zespołów wykonawców i wspomaganie prac.repozytorium java,net i i muszą być zatwierdzone przez prowadzących zajęcia w celu przekazania wykonanego oprogramowanie na podstawie modelu wykonanego w 6-8 tygodni Implementacja2 PU (warstwa prezentacji i klienta): opracowanie wspólnego szablonu tworzonych formularzy, ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client), koncepcja i kod testów akceptacyjnych (Selenium lub ręczne), Podczas 10-tygodnia wyniki prac umieszczane są w wykonanej implementacji do integracji przez wydzielony zespół Scenariusz dla trzech zespołów Wszystkie grupy Rozbudowa diagramu PU (Sprint Backlog): planowanie nowych PU, uwzględnienie wniosków z raportów opracowanych przez Scrum Master z wykonanych PU. Rozdział nowych PU do 3 grup wykonawców Definicja PU (przypadku użycia): opis słowny wg standardowego formularza scenariusz należy.4-10 Kontrola przyjętego standardu formularzy, Wykonanie testów projektu typu EE Scenariusz dla jednego zespołu 5-10 Integracja 3 projektów, typu EE (wg podanego tutorialu) dostarczonych w 10 tygodniu, etap 1-y 4-10 Ocena 5-10

6 12 Daily Scrum wykonać za pomocą diagramu aktywności (ewentualnie diagramu sekwencji i diagramu stanów). Każda grupa opracowuje przypadki użycia jako specyfikację tych wymagań funkcjonalnych, które opracowała w poprzednich krokach. Podczas 11-tygodnia wynik prac umieszczane są w repozytorium java,net i są oceniane przez prowadzących zajęcia Przedstawienie wyników prac z 11 tygodnia Projekt PU (wersja końcowa): diagram klas (integracja przez Scrum Master diagramów klas z 11 tygodnia) diagramy sekwencji, diagramy aktywności diagramy stanów integracja raportów wygenerowanie dokumentacji zawierającej wymienione wyżej elementy identyfikowane na podstawie PU, wykorzystanie wzorców projektowych (zalecane). Podczas 12-tygodnia wyniki prac umieszczane są w wykonanego modelu do implementacji 3-5 Integrowanie PU opracowanych przez diagramu PU Integrowanie projektów PU opracowanych przez diagramu klas, eliminacja redundancji w projekcie, Analiza raportów inspektorów, ocena wpływu zidentyfikowanych problemów na przebieg projektu Integracja 4 projektów typu EE (wg podanego tutorialu) etap 2-i Daily Scrum Implementacja1 PU (warstwa biznesowa) rozwój oprogramowania wykonanego w 2-ym sprincie i zintegrowanego przez zespół czwarty w tygodniu 12: kod warstwy biznesowej na podstawie modelu z tygodnia koncepcja i kod testów jednostkowych i integracyjnych wykonanych za pomocą JUnit usuwanie błędów pomiar metryk oprogramowania za pomocą narzędzia CKJM ewentualna refaktoryzacja kodu w celu poprawy 2-5 Włączenie się do zespołów wykonawców i wspomaganie prac Rozwój warstwy integracji opartej na technologii JPA 2-5

7 14 Daily Scrum 15 Sprint review meeting & Sprint retrospective meeting (1.5h) nieprawidłowych wartości metryk (w szczególności RFC, LCOM3) powtórzenie testów jednostkowych w przypadku refakatoryzacji Podczas 13-tygodnia wyniki prac umieszczane są w wykonanego oprogramowanie na podstawie modelu wykonanego w tygodni Implementacja2 PU (warstwa prezentacji i klienta): opracowanie wspólnego szablonu tworzonych formularzy, ujednolicenie funkcjonalności formularzy w zakresie ich obsługi i walidacji danych kod warstwy prezentacji i klienta (technologia JSF lub/i Enterprise Application Client), koncepcja i kod testów akceptacyjnych (Selenium lub ręczne), Podczas 14-tygodnia wyniki prac umieszczane są w wykonanej implementacji do integracji przez wydzielony zespół Podsumowanie 4-10 Kontrola przyjętego standardu formularzy, Wykonanie testów projektu typu EE 4-10 Stosowany proces wytwarzania oprogramowania - Scrum Stosowany będzie proces wytwarzania oprogramowania wzorowany na metodyce Scrum. Z metodyki tej zaczerpnięte zostały następujące elementy: Daily Scrum - krótkie spotkanie dotyczące aktualnego statusu projektu, w trakcie którego następuje synchronizacja prac wykonywanych przez poszczególne zespoły. W spotkaniu bierze udział prowadzący, Scrum Master i dokładnie jeden przedstawiciel każdej grupy projektowej, pozostali członkowie grup projektowych mogą brać udział w spotkaniu tylko jako obserwatorzy. W trakcie spotkania przedstawiciel zespołu powinien udzielić odpowiedzi na następujące trzy pytania: o Co zespół zrobił od poprzedniego Daily Scrum? o Co zespół planuje zrobić do następnego Daily Scrum?

8 o Co przeszkadza zespołowi w realizowaniu zaplanowanych zadań? Product Owner - rola pełniona przez prowadzącego. Product Owner decyduje o priorytetach poszczególnych zadań, tym samym do niego należy rozstrzygający głos odnośnie zestawu zagadnień wybieranych do Sprint Backlog w trakcie Sprint planning meeting. Product Owner decyduje również o tym, czy dane zagadnienie zostało zrealizowane w wystarczającym stopniu i z wystarczającą jakości, aby mogło zostać uznane za zaliczone. Scrum Master - rola pełniona przez 3 studentów każdy przez okres jednego sprintu. Powinni oni w miarę możliwości rozwiązywać problemy zagrażające sukcesowi sprintu. Administrują systemem java.net. Pewne zadania zostały wyspecyfikowane w tabeli 1. Sprint - ograniczona czasowo do 4-5 tygodni iteracja (patrz Tab. Przebieg realizacji projektu) w trakcie której zespoły pracują nad przekształceniem przydzielonych przypadków użycia w nadającą się do przekazania klientowi funkcjonalność. Sprint Backlog - lista błędów, zadań i przypadków użycia z przypisanymi punktami odzwierciedlającymi ich trudność, które mają zostać zrealizowane w trakcie sprintu. Powstaje w systemie java.net w trakcie Sprint planning meeting. Sprint planning meeting - 70 minutowe spotkanie rozpoczynające każdy sprint. W trakcie spotkania definiuje się Sprint Backlog. W spotkaniu biorą udział Product Owner, Scrum Master, administrator i przynajmniej jeden przedstawiciel każdej grupy projektowej. Sprint retrospective meeting - spotkanie podsumowujące projekt. W trakcie spotkania powinna odbyć się dyskusja dotycząca możliwości usprawnienia stosowanego procesu wytwarzania oprogramowania. Sprint review meeting - 20 minutowe spotkanie podsumowujące sprint. W trakcie spotkania prezentowane oraz omawiane są funkcjonalności zrealizowane w trakcie kończącego się sprintu. Przepływ pracy Przepływ pracy w projekcie wynika bezpośrednio z przedstawionego harmonogramu w tabeli 1: Przebieg realizacji projektu. Cały projekt jest podzielony na 3 sprinty. Każdy sprint składa się z takich samych elementów. Zaczyna się spotkaniem Sprint planning meeting, w trakcie którego wybierana są zagadnienia do zrealizowania w trakcie sprintu, a kończy się spotkaniem Sprint review meeting, w trakcie którego prezentowane są uzyskane wyniki. W trakcie sprintu, raz w tygodniu odbywają się spotkania Daily Scrum, na których raportowany jest aktualny status. Najważniejszym zadaniem w trakcie sprintu jest rozwiązywanie zaplanowanych na sprint zagadnień, czyli błędów, zadań i przypadków użycia. Każdy wynik prezentowany podczas Daily Scrum jest oceniane za pomocą przydzielanych punktów, podanych w tabeli 1, zarówno zespołowi, jak i kierownikowi (Scrum Master) Realizacja przypadku użycia może być stosunkowo zawiła i obejmuje zazwyczaj wiele różnych aktywności. W związku z tym zaleca się, aby kierownik zespołu wprowadził w systemie java.net zadania składające się na realizację danego przypadkiem użycia i poprzydzielał je członkom zespołu. Role projektowe Jeden projekt będzie realizowany przez wszystkich studentów zapisanych na dany termin, czyli zespół projektowy będzie się składał z około osoby. Podział na 4-6-osobowe podgrupy o Programista / modelarz 2-3 osoby w podgrupie, odpowiedzialne za specyfikowanie wymagań, projektowanie aplikacji, programowanie i testowanie na poziomie testów jednostkowych o Kierownik - 1 osoba w podgrupie, odpowiedzialna za koordynowanie prac wewnątrz podgrupy (np. definiowanie niepunktowanych podzadań w java.net), osoba kontaktowa w komunikacji między podgrupami, równocześnie pełni rolę programisty / modelarza

9 o Inspektor / tester 1-2 osoby w podgrupie, odpowiedzialne za przeglądanie i weryfikowanie wymagań oraz modelu (przygotowują raport inspektora) oraz za testy akceptacyjne. Listy kontrolne dla inspektora: Lista kontrolna diagramów hierarchii okien Lista kontrolna opisów PU Lista kontrolna diagramów klas Lista kontrolna diagramów sekwencji Lista kontrolna diagramów stanów Szablon raportu inspektora Administrator 1 osoba w całym projekcie, odpowiedzialne za przygotowywanie i konserwowanie środowiska programistycznego ze szczególnym uwzględnieniem systemu ciągłej integracji oraz za raportowanie i przypisywanie błędów znalezionych przy pomocy systemu ciągłej integracji. Funkcja cykliczna, kadencja trwa 1 sprint, każdy kolejny administrator powinien pochodzić z innej 4-6-osobowej podgrupy. Scrum Master. Funkcja cykliczna, kadencja trwa 4-5 tygodnie, jedna osoba w projekcie. Każdy kolejny Scrum Master powinien pochodzić z innej 3-osobowej podgrupy. Scrum Master oprócz swojej funkcji powinien wykonywać zadania związane z implementacją realizowanego przez jego grupę przypadku użycia. Administruje systemem java.net, w szczególności ma uprawnienia do zmieniania osoby przypisanej do błędu. Jak wybrać kierownika oraz inspektora Przygotowywane artefakty Faza modelowania o scenariusz PU, najlepiej w postaci diagramu aktywności, czas życia dokumentu - czas trwania całego projekt o specyfikacja testów akceptacyjne do PU, czas życia dokumentu - czas trwania całego projekt albo do momentu zautomatyzowania w postaci wykonywalnej w systemie ciągłej integracji o diagram sekwencji do PU o diagram klas do PU o diagram stanów (jeżeli jest potrzebny) do PU o raport inspektora (można generowac z Java.net albo przygotowywać ręcznie na podstawie wspomnianego powyżej szablonu) Faza implementacji o kod (działająca aplikacja) obowiązkowa separacja kodu warstwy biznesowej od warstwy prezentacji o zautomatyzowane testy jednostkowe (JUnit) o uruchomione manualnie lub zautomatyzowane w wybranym narzędziu testy akceptacyjne Dokumenty wytwarzane poza fazami, czas życia dokumentu - czas trwania całego projekt

10 o o diagram PU diagramy ilustrujące architekturę całego systemu, np.: diagram klas domenowych, diagram ilustrujący podział systemu na komponenty Czas życia dokumentu wynosi 1 sprint (kodu i zautomatyzowanych testów nie zaliczamy do dokumentów), chyba że napisano w opisie dokumentu inaczej. Dokumenty o czasie życia wynoszącym 1 sprint nie muszą być aktualizowane po zakończeniu sprintu, w którym żyły. Pozostałe dokumenty muszą być aktualizowane aż do końca projektu. Odpowiedzialna za aktualizację dokumentu jest grupa, która wprowadziła zmianę, w efekcie której dokument musi zostać zaktualizowany. Zalecane narzędzia UML Visual Paradigm 12.0 Community Edition (każdy diagram powinien powstawać w osobnym pliku) Netbeans 8.02, Java SE 8, Java EE 7 Hudson - na potrzeby systemu ciaglej integracji został udostępniony serwer: SonarQube do oceny jakości oprogramowania: Maven SVN : https://www.java.net JUnit 4: FitNesse, Selenium lub inne narzędzie do testów funkcjonalnych: Warunki zaliczania i metoda oceniania Ocena końcowa będzie zależeć od liczby zrealizowanych i zaliczonych zagadnień (zagadnienie może być przypadkiem użycia, zadaniem albo błędem), które wcześniej zostały zgłoszone na Liczba punktów zależy głównie od liczby wykonanych zagadnień i ich znaczenia w projekcie. Waga wykonanych zagadnień będzie omawiana podczas poszczególnych spotkań w ramach każdego sprintu. Warunkiem uzyskania danej oceny jest zdobycie odpowiedniej liczby punktów, wg tabeli 2: Tabela 2 Ocena Punkty 3, , , , , Literatura:

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc.

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc. Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00-19.45 a podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie

Bardziej szczegółowo

Programowanie Zespołowe

Programowanie Zespołowe Programowanie Zespołowe Programowanie zwinne dr Rafał Skinderowicz mgr inż. Michał Maliszewski Programowanie zwinne Grupa metodyk wytwarzania oprogramowania oparta na modelu iteracyjno-obiektowym Powstała

Bardziej szczegółowo

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Głó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ółowo

Scrum. Zwinna metodyka prowadzenia projektów

Scrum. Zwinna metodyka prowadzenia projektów Scrum Zwinna metodyka prowadzenia projektów Plan prezentacji 1. Ogólna idea 2. Najważniejsze elementy 3. Role 4. Czynności 5. Artefakty 6. Wnioski 7. Literatura Źródło ilustracji: http://commons.wikimedia.org/wiki/file:scrum.jpg

Bardziej szczegółowo

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska Wprowadzenie do metodyki SCRUM mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska SCRUM Scrum (skrót od scrummage) - metoda ponownego uruchomienia gry w rugby zwana również formacją

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński Wskazówki projektowe Programowanie Obiektowe Mateusz Cicheński Przydatne zasady SOLID Wzorce struktury aplikacji MVC MVP MVVM Metody wytwarzania oprogramowania Manifest Zwinnego Wytwarzania Oprogramowania

Bardziej szczegółowo

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań Metodyka Scrum Podejście tradycyjne plan wykonanie sekwencyjna natura wykonywanych zadań analiza i definiowanie wymagań projektowanie rozwiązań kodowanie rozwiązań testowanie odstępstwo od planu jest kosztowne

Bardziej szczegółowo

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

Bardziej szczegółowo

Usługa: Testowanie wydajności oprogramowania

Usł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ółowo

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora SCRUM Metodyka prowadzenia projektów Na podstawie prezentacji B. Kuka i W. Sidora Wprowadzenie. Scrum jest metodyką prowadzenia projektów zaliczaną do metodyk zwinnych, zgodnych z Agile Manifesto. Scrum

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarzą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

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

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

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

Egzamin / zaliczenie na ocenę* WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli

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

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT 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ółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

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

Asynchroniczne interfejsy WWW

Asynchroniczne interfejsy WWW Asynchroniczne interfejsy WWW Metodyki zwinnego wytwarzania oprogramowania mgr inż. Rafał Grycuk Strona służbowa: http://iisi.pcz.pl/~rgrycuk/ Kontakt: rafal.grycuk@iisi.pcz.pl Konsultacje: Środa, 12-14

Bardziej szczegółowo

Testowanie w procesie Scrum

Testowanie w procesie Scrum Tilo Linz Testowanie w procesie Scrum Przewodnik po zarządzaniu jakością oprogramowania w świecie programowania zwinnego Przekład: Jakub Niedźwiedź APN Promise, Warszawa 2014 v 1 Wprowadzenie........................................1

Bardziej szczegółowo

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7 AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli

Bardziej szczegółowo

Scrum w praktyce. Michał Piórek

Scrum w praktyce. Michał Piórek Scrum w praktyce Michał Piórek Slajd 2 z 28 Plan prezentacji Scrum metodyka prowadzenia projektów Opis projektu systemu do rozliczania podatków Struktura zespołu i jego role Zespół w firmie Podatnik.info

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

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

Planowanie i realizacja zadań w zespole Scrum

Planowanie i realizacja zadań w zespole Scrum MetaPack IT Academy Uniwersytet Zielonogórski Planowanie i realizacja zadań w zespole Scrum Paweł Przybyła Professional Scrum Master (www.scrum.org) Planowanie i realizacja zadań w zespole Scrum Agenda:

Bardziej szczegółowo

Usługa: Audyt kodu źródłowego

Usł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ółowo

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

Programowanie zespołowe

Programowanie 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ółowo

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Dokument 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ółowo

Testowanie oprogramowania

Testowanie 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ółowo

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne. Załącznik nr 1a do Zapytania ofertowego nr POIG.08.02-01/2014 dotyczącego budowy oprogramowania B2B oraz dostawcy sprzętu informatycznego do projektu pn. Budowa systemu B2B integrującego zarządzanie procesami

Bardziej szczegółowo

Strategia testów mająca doprowadzić do osiągnięcia pożądanych celów

Strategia 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ółowo

Inżynieria oprogramowania - opis przedmiotu

Inżynieria oprogramowania - opis przedmiotu Inżynieria oprogramowania - opis przedmiotu Informacje ogólne Nazwa przedmiotu Inżynieria oprogramowania Kod przedmiotu 11.3-WK-IiED-IO-W-S14_pNadGenRB066 Wydział Kierunek Wydział Matematyki, Informatyki

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy 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ółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania Rodzaj zajęć: wykład, laboratorium TESTOWANIE OPROGRAMOWANIA Software testing Forma

Bardziej szczegółowo

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Joanna Siemińska o mnie Absolwentka Politechniki Warszawskiej Orange Outbox Europejska Organizacja Badań Jądrowych w Genewie (CERN) TouK Certyfikat

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

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

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie

Bardziej szczegółowo

Zarządzanie Projektami Plan kursu

Zarządzanie Projektami Plan kursu Zarządzanie Projektami Plan kursu opracował Wojciech Walczak Dokument ten przedstawia plan kursu Zarządzanie projektami. Uczestnicy kursu zobowiązują się do przeprowadzenia wybranego przez siebie projektu

Bardziej szczegółowo

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca

Bardziej szczegółowo

Etapy życia oprogramowania

Etapy ż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ółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Jarosł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ół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

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia

Bardziej szczegółowo

I. Raport wykonywalności projektu

I. Raport wykonywalności projektu Spis treści: " I. " Raport wykonywalności projektu..." str. 2 " II. " Glosariusz projektu... " str. 4 " III. " Diagramy relacji encja-związek..." str. 6 " IV. " Diagramy przepływu danych..." str. 7 " V.

Bardziej szczegółowo

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013 SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE. Jacek Panachida

Web frameworks do budowy aplikacji zgodnych z J2EE. Jacek Panachida Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida Cel pracy Analiza wybranych ram projektowych dostępnych dla platformy Java Warunki selekcji napisany z wykorzystaniem języka Java oraz

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

Bardziej szczegółowo

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Etapy ż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ółowo

KARTA PRZEDMIOTU. Projekt zespołowy D1_10

KARTA PRZEDMIOTU. Projekt zespołowy D1_10 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Projekt zespołowy D1_10 Nazwa przedmiotu (j. ang.): Team Project Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia:

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej 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ółowo

Testowanie oprogramowania. Piotr Ciskowski

Testowanie 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ół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

IBM Rational Software Architect uproszczona instrukcja użytkowania

IBM Rational Software Architect uproszczona instrukcja użytkowania IBM Rational Software Architect uproszczona instrukcja użytkowania TOMASZ ŁUKASZUK na podstawie Software Developer's Jurnal Extra Nr 18 STRESZCZENIE: Dokument przedstawia ogólne informacje na temat narzędzia

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Projekt zespołowy D1_10

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Projekt zespołowy D1_10 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:

Bardziej szczegółowo

ECDL ZARZĄDZANIE PROJEKTAMI

ECDL ZARZĄDZANIE PROJEKTAMI ECDL ZARZĄDZANIE PROJEKTAMI EUROPEJSKI CERTYFIKAT UMIEJĘTNOŚCI KOMPUTEROWYCH ZARZĄDZANIE PROJEKTAMI Syllabus v. 1.0 Oficjalna wersja dokumentu jest dostępna w serwisie WWW Polskiego Biura ECDL www.ecdl.pl

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

Grupa treści kształcenia, w ramach której przedmiot jest realizowany Przedmiot kierunkowy

Grupa treści kształcenia, w ramach której przedmiot jest realizowany Przedmiot kierunkowy SYLLABUS na rok akademicki 0113/014 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu

Bardziej szczegółowo

Załą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 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ółowo

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Programowanie usług sieciowych

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Programowanie usług sieciowych Politechnika Krakowska im. Tadeusza Kościuszki Karta przedmiotu Wydział Fizyki, Matematyki i Informatyki obowiązuje w roku akademickim 2011/2012 Kierunek studiów: Informatyka Forma studiów: Stacjonarne

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20 Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:

Bardziej szczegółowo

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Akademia MetaPack Uniwersytet Zielonogórski Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Krzysztof Blacha Microsoft Certified Professional Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Agenda:

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa : Kierunek: Informatyka Rodzaj : obowiązkowy w ramach specjalności: Inżynieria oprogramowania Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE APLIKACJI INTERNETOWYCH Internet Application Development

Bardziej szczegółowo

Praktyczne wykorzystanie MS Project 2010

Praktyczne wykorzystanie MS Project 2010 Praktyczne wykorzystanie MS Project 2010 LondonSAM Polska, Kraków 2013 Firma WHITECOM Project Experience oraz LondonSAM Polska zapraszają serdecznie do udziału w szkoleniu poświęconym nauce narzędzia MS

Bardziej szczegółowo

edycja 1 opracowany zgodnie z Zarządzeniami Wewnętrznymi PWr. nr 14/2012 i 15/2012 i 34/2012

edycja 1 opracowany zgodnie z Zarządzeniami Wewnętrznymi PWr. nr 14/2012 i 15/2012 i 34/2012 Wrocław, 18.05.2015 Program kształcenia i plan studiów podyplomowych: Android i ios nowoczesne aplikacje mobilne edycja 1 opracowany zgodnie z Zarządzeniami Wewnętrznymi PWr. nr 14/2012 i 15/2012 i 34/2012

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Inżynieria oprogramowania II

Inż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ółowo

Zapytanie ofertowe 13-09-2013

Zapytanie 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ółowo

Piotr Ślęzak. Gdzie się podziała jakość

Piotr Ślęzak. Gdzie się podziała jakość Piotr Ślęzak Gdzie się podziała jakość Działamy na styku Biznesu i IT Analiza biznesowa Kontrola jakości Doradztwo Projekty Szkolenia ForProgress spółka z ograniczoną odpowiedzialnością sp.k. kontakt@forprogress.com.pl

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI Sprawne zarządzanie projektami Tworzenie planów projektów Zwiększenie efektywności współpracy Kontrolowanie i zarządzanie zasobami jak również pracownikami Generowanie raportów Zarządzaj projektami efektywnie

Bardziej szczegółowo

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Architektura zorientowana na usługi

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Architektura zorientowana na usługi Politechnika Krakowska im. Tadeusza Kościuszki Karta przedmiotu Wydział Fizyki, Matematyki i Informatyki obowiązuje w roku akademickim 2011/2012 Kierunek studiów: Informatyka Forma studiów: Stacjonarne

Bardziej szczegółowo

szkolenia pod drzewem Wybrane Techniki XP bnd 2008 Tomasz Włodarek. Materiał udostępniany na podstawie licencji Creative Commons (by-nc-nd) 1.00.

szkolenia pod drzewem Wybrane Techniki XP bnd 2008 Tomasz Włodarek. Materiał udostępniany na podstawie licencji Creative Commons (by-nc-nd) 1.00. szkolenia pod drzewem Wybrane Techniki XP 1.00.00 bnd Wybrane techniki XP współwłasność kodu źródłowego (collective code ownership) częsta/ciągła integracja (continuous integration) programowanie w parach

Bardziej szczegółowo

Całościowe podejście do testowania automatycznego dla programistów. /C#/PHP (TDD, BDD, Spec. by Example, wzorce, narzędzia)

Całościowe podejście do testowania automatycznego dla programistów. /C#/PHP (TDD, BDD, Spec. by Example, wzorce, narzędzia) Program szkolenia: Całościowe podejście do testowania automatycznego dla programistów Java /C#/PHP (TDD, BDD, Spec. by Example, wzorce, narzędzia) Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia 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ółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

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

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną

Bardziej szczegółowo

Szczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:

Szczegół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ół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

Zagadnienia. Inżynieria Oprogramowania

Zagadnienia. Inżynieria Oprogramowania Zagadnienia Co to jest extreme Programming (XP) Czym charakteryzują się tzw. lekkie metodyki zarządzania procesem produkcji oprogramowania Reguły i praktyki XP Dlaczego i kiedy można a w jakich przypadkach

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

Michał Olejnik. 22 grudnia 2009

Michał Olejnik. 22 grudnia 2009 Continuous TDD Politechnika Wrocławska Informatyka 22 grudnia 2009 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda

Bardziej szczegółowo

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A. Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.

Bardziej szczegółowo

Programowanie aplikacji biznesowych

Programowanie aplikacji biznesowych Programowanie aplikacji biznesowych Zajęcia prowadzone będą zgodnie z nowatorską techniką dydaktyczną: Nauczanie przez projekt Project-based learning (PBL) W czasie kursów zespół studentów zrealizuje zaawansowaną

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

Bardziej szczegółowo

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0)

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Informacje: Nazwa: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Kod: Kategoria: Grupa docelowa: Czas trwania:

Bardziej szczegółowo

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Załącznik nr 2 do umowy nr 37/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania

Bardziej szczegółowo