Rubik s Manager - SDP
|
|
- Aneta Małecka
- 8 lat temu
- Przeglądów:
Transkrypt
1 Rubik s Manager - SDP Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 27 maja
2 Spis treści 1 Wprowadzenie Cel Definicje Załączniki Omówienie reszty dokumentu Omówienie projektu Cel, zakres i objectives projektu Produkty projektu Procedura zmian w planie projektu Organizacja projektu Struktura organizacyjna Kontakty zewnętrzne Role i zadania Analiza punktów funkcyjnych Nieunormowana wartość punktów funkcyjnych Całkowity stopień wpływu Unormowana wartość punktów funkcyjnych Zarzadzanie projektem Plan projektu Iteracje projektu Wydania Harmonogram projektu (dwóch pierwszych iteracji) Zasoby Budżet Nadzór i kontrola projektu Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli jakości Plan raportów Plany procesów technicznych Programowanie Metody, narzędzia i stosowane technologie Plan infrastruktury Plan akceptacji produktu
3 7 Plany pomocnicze Plan zarządzania zmianami Plan oceny Plan dokumentacji Plan zapewnienia jakości Plan rozwiązywania problemów Plan ulepszania Historia zmian 17 3
4 1 Wprowadzenie 1.1 Cel Dokument "Plan projektu"ma na celu opisać czasowy i osobowy podział pracy nad projektem Rubik s Magnager. 1.2 Definicje RM - skrót od nazwy produktu, tj. Rubik s Manager, kostka Rubika - łamigłówka logiczna w postaci sześcianu o ruchomych ścianach; także potoczna nazwa na pochodne tej łamigłówki, speedcubing - sport polegający na układaniu kostki Rubika na czas, World Cubing Association - organizacja ustalająca regulamin organizowania zawodów w speedcubingu, PM - project manager. 1.3 Załaczniki Wizja Przypadki użycia SAD 1.4 Omówienie reszty dokumentu Dokument zawiera listę osób biorących udział w projekcie, przydział osób do zadań, częściowy terminarz realizacji zadań, plan nadzoru i kontroli nad projektem, analizę punktów funkcyjnych projektu, wskazania narzędzi, technologii i metodologii wykorzystywanych w projekcie. 4
5 2 Omówienie projektu 2.1 Cel, zakres i objectives projektu Projekt ma na celu stworzenie programu Rubik s Manager umożliwiającego przeprowadzanie treningów w speedcubingu w różnych trybach i wariantach wraz z przechowywaniem rezultatów, generowaniem statystyk. RM będzie zawierał narzędzia pomocne przy doskonaleniu stosowanych metod układania. Pozwoli na przeprowadzanie turniejów między użytkownikami z całego świata, udostępni transmisje i rankingi dla zainteresowanych. Będzie to także kompletny system potrzebny do zorganizowania lokalnych zawodów. Możliwa będzie ponadto obsługa przydatnych urządzeń peryferyjnych wykorzystywanych w speedcubingu. 2.2 Produkty projektu Podczas realizacji projektu wytworzono dokumenty: Wizja Model przypadków użycia Model dziedziny SAD SDP Plan testów Prezentacja projektu Zaimplementowane zostaną programy Rubik s Manager Personal Oprogramowanie serwera Rubik s Manager 2.3 Procedura zmian w planie projektu Wersja SDP Data Komentarz Wersja wstępna 5 II 2007 Początek projektu Wersja robocza 1 III 2007 Modyfikacje dotyczące dziedziny Wersja robocza mk.2 23 III 2007 Zmiany w składzie zespołu Wersja ostateczna 24 V 2007 Zmiany w terminie realizacji projektu 5
6 3 Organizacja projektu 3.1 Struktura organizacyjna Członkowie zepołu. Personalia Sebastian Chojniak Łukasz Krupa Grzegorz Łuczyna Funkcja architekt, programista analityk, programista PM, programista 3.2 Kontakty zewnętrzne Zespół kontaktuje się z Jackiem Sroką, prowadzącym zajęcia z Inżynierii Oprogramowania, który kontroluje projekt i udziela konsultacji w istotnych kwestiach projektowych i technicznych. Ponadto zespół utrzymuje kontakt z przedstawicielem World Cubing Association. Rozmowy dotyczą użyteczności i funkcjonalności programu RM. 3.3 Role i zadania Rola PM Zadania nadzór nad projektem zatwierdzanie zmian w projekcie kontrola terminowości pracy analityk analiza rynku i ryzyka w projekcie uzyskiwanie sugerowanych wymagań od speedcuberów projektowanie dokumentów architekt stworzenie abstrakcyjnego modelu systemu stworzenie projektu systemu 6
7 Rola programista Zadania implementacja projektu według modelu architektów informowanie architektów o problemach w projekcie tester wykrywanie błędów w oprogramowaniu 7
8 4 Analiza punktów funkcyjnych 4.1 Nieunormowana wartość punktów funkcyjnych Internal Logical File trening speedcubera - pomiar czasów (low: 7), trening speedcubera - poprawa techniki (high: 15), organizowanie zawodów internetowych (average: 10). External Logical File uczestniczenie w zawodach internetowych (average: 7), wysyłanie wyników na centralny serwer (low: 5), przeglądanie listy zawodów (low: 5), generowanie algorytmów rozwiązujących (average: 7). External Input obsługa stackmaty (average: 4), wprowadzanie wyników zawodów stacjonarnych (low: 3). External Output przeglądanie bazy wiedzy (low: 4), kibicowanie w zawodach internetowych (average: 5), symulator kostki rubika (average: 5). External Inquiry generowanie algorytmów mieszających (low: 3). UFPC = 80 8
9 4.2 Całkowity stopień wpływu Data Communications: 4 Distributed Data Processing: 3 Performance: 1 Heavily Used Configuration: 1 Transaction Rate: 2 Online Data Entry: 3 End-User Efficiency: 1 Online Update: 1 Complex Processing: 0 Reusability: 0 Installation Ease: 2 Operational Ease: 3 Multiple Sites: 1 Facilitate Change: 1 TDI = Unormowana wartość punktów funkcyjnych VAF = * TDI = 0.88 AFPC = UFPC * VAF =
10 5 Zarzadzanie projektem 5.1 Plan projektu Iteracje projektu Analiza Analiza jest pierwszą fazą projektu i w dużej mierze od niej zależy powodzenie całego projektu. Podstawowym zadaniem jest zebranie od klienta (fizycznie: osób zainteresowanych używaniem wytworzonego systemu) wymagań funkcjonalnych oraz oczekiwań w stosunku do stosowanych rozwiązań. Istotne jest dokładne sprecyzowanie ram systemu. Dodatkowo podczas analizy wnikliwie musi zostać prześledzona demografia rynku odbiorców oraz istniejące już systemy o podobnym zastosowaniu. Projektowanie W tej fazie powinien powstać model dający możliwie najlepszy pogląd o architekturze tworzonego systemu. Podjęte muszą zostać decyzje na temat wykorzystywanych technologii i rozwiązań (które nie będą implementowane przez programistów zaangażowanych w projekt). Iteracja projektu, jaką jest projektowanie zachodzi na fazę analizy - model jest na bieżąco rozwijany i poprawiany po sprecyzowaniu nowych wymagań funkcjonalnych. W każdym momencie tworzenia modelu musi być wyraźnie wskazany podział systemu na warstwy. Po uzyskaniu klarownego modelu tworzony jest wstępny plan testów dla systemu uwzględniający zarówno testy funkcjonalności, jak i wydajności. Implementacja Programiści implementują system zgodnie z uzyskanym w wyniku projektowania modelem. Nadzór nad zgodnością i spójnością modułów sprawuje PM w porozumieniu z architektami. Równocześnie weryfikowana jest spełnialność wymagań stawianych przez klienta. Po zaimplementowaniu spójnego fragmentu systemu dokonywane są wstępne testy tegoż fragmentu. Wymagania stawiane wobec programistów obejmują: pisanie kodu zgodnie z przyjętym standardem oraz dokumentowanie pisanego kodu. Testowanie Oprócz wstępnych i częściowych testów tworzonych modułów planowane jest wykonanie testów całościowych. Ich opis i analiza jest początkowo tworzona w fazie projektowania i rozwijana po zakończeniu fazy implementacji. Testowanie obejmuje ostateczną weryfikację i walidację systemu. Wdrażanie i aktualizacje Po zakończeniu fazy testowania następuje wdrażanie systemu, czyli odbiór finalnego produktu przez klienta. Po tej fazie nie jest planowana przebudowa systemu. Są natomiast planowane regularne aktualizacje mające zapewnić zgodność ze zmianami w regulaminach na których opiera się projekt Rubik s Manager. Planowane jest także rozbudowywanie systemu w miarę rosnących potrzeb użytkowników. 10
11 5.1.2 Wydania Planowane jest regularne udostępnianie wersji beta systemu, nim jeszcze powstanie finalna wersja. Użytkownicy tychże wersji uzyskają możliwość zgłaszania błędów i sugestii dotyczących funkcjonowania. Po wdrożeniu finalnej wersji projektu udostępniane będą wspomniane wcześniej aktualizacje. 11
12 5.1.3 Harmonogram projektu (dwóch pierwszych iteracji) 12
13 5.1.4 Zasoby Plan zatrudniania pracowników Nie przewiduje się zatrudniania pracowników innych niż wymienieni w składzie zespołu we wcześniejszej części tegoż dokumentu. Plan szkoleń Plan szkoleń Projekt Data zakończenia Latex-podstawy 12 II 2007 SVN - użytkowanie 26 II 2007 UML - podstawowe diagramy 14 III 2007 Podstawowe wzorce projektowe 7 V Budżet Środki budżetowe w całości pochodzą z własnych wkładów członków zespołu realizującego projekt Rubik s Manager. 13
14 5.2 Nadzór i kontrola projektu Plan zarzadzania wymaganiami Wymagania projektu zostały sprecyzowane na etapie analizy systemu i są opisane w stosownych dokumentach. Nad zgodnością tworzonych fragmentów systemu z wymaganiami czuwa PM i architekci. Wszelkie zmiany wymagań (nie zwiększające zakresu projektu) są konsultowane z analitykami i architektami. Po spisaniu stosownego dokumentu o zmianach jest on udostępniany (w trybie: do obowiązkowego zapoznania się) wszystkim osobom zaangażowanym w projekt Plan zarzadzania harmonogramem Nad czasowym rozłożeniem projektu czuwa PM. W szczególności jest on odpowiedzialny za wykonywanie zaplanowanych elementów na czas. Wprowadza ponadto korekty w harmonogramie w przypadku opóźnionego lub przyspieszonego zakończenia niektórych etapów. Aktualnie obowiązująca wersja harmonogramu jest stale dostępna dla wszystkich osób zaangażowanych w realizację projektu Plan kontroli jakości Regularne prezentacje zaimplementowanych elementów systemu reprezentantom środowiska speedcuberów. Dostosowanie projektu do uwag speedcuberów, o ile nie zmienia to jego zakresu. Testowanie komponentów systemu, zgodnie z dokumentem "Plan testów". Weryfikowanie zachowania standardów kodowania i prowadzonej dokumentacji Plan raportów Wszelkie zmiany w projekcie dokumentowane są w formie raportów, które dokładnie uwzględniają ich zakres. Osoby zaangażowane w realizację projektu, dla pracy których zmiany te mają znaczenie, pisemnie potwierdzają zapoznanie się z raportem. Dodatkowo cały zespół odpowiedzialny za realizację projektu Rubik s Manager spotyka się regularnie - co tydzień. Podjęte na spotkaniu decyzje zostają spisane również w formie raportu. Wszystkie raporty dostępne są przez cały okres realizacji projektu do wglądu dla wszystkich członków zespołu. Nie dotyczy to jednak raportów dotyczących budżetu, które dostępne są wyłącznie dla osób odpowiedzialnych za zarządzanie projektem. 14
15 6 Plany procesów technicznych 6.1 Programowanie System podzielony jest na moduły, których programowanie przebiega niezależnie. Zespół programistów ustala sposób komunikacji między modułami, wybrane ustalenia są dokumentowane. Programiści dzielą miedzy sobą zadania, które wykonywać będą samodzielnie. 6.2 Metody, narzędzia i stosowane technologie Metody: RUP (Rational Unified Process) UML (Unified Modeling Language) Narzędzia: SVN - system kontroli wersji Violet - narzędzie od modelowania UML Umlet - narzędzie do modelowania UML Umbrello - narzędzie do modelowania UML JMeter - program do przeprowadzania testów GCC - kompilator języka C++ GDB - debugger Gimp - narzędzie do tworzenia szaty graficznej Technologie: PostgreSQL - baza danych Open GL J2EE Sopcast - narzędzie do transmisji video Adobe Flex 2 15
16 6.3 Plan infrastruktury Osoby biorące udział w projekcie korzystają z własnego sprzętu komputerowego. Tworzenie oprogramowania przebiega w warunkach domowych. Niezbędne informacje przekazywane są miedzy członkami zespołu za pomocą komunikatorów internetowych. Na cele projektu przewidziany jest zakup licencji na niezbędne narzędzia. Co tygodniowo zespół spotyka się by omówić co zrobił i jakie są plany na następne działania. Miejsce spotkania ustalane jest na dwa dni przed spotkaniem i nie jest statycznie określone. 6.4 Plan akceptacji produktu Ukończona pierwsza kompletna wersja systemu przechodzi przygotowane testy. Produkt udostępniany jest kilku wybranym zainteresowanym osobom, w celu otrzymania opinii na temat systemu. W przypadku braku krytycznych niedociągnięć uznaje się produkt za gotowy do dystrybucji. 16
17 7 Plany pomocnicze 7.1 Plan zarzadzania zmianami Wszelkie zmiany w projekcie będą odnotowywane w specjalnym rejestrze. Wraz z wprowadzona zmianą podany będzie powód jej wprowadzenia. 7.2 Plan oceny Gotowe komponenty przejdą szereg testów, na ich podstawie ustalona zostanie ocena ich jakości. W przypadku wystąpienia błędów uniemożliwiających poprawna prace całości komponent dostaje ocenę negatywną i wraca do fazy implementacji. 7.3 Plan dokumentacji Równolegle do tworzenia systemu wykonywana będzie dokumentacja wykonanych prac. Główny nacisk kładziony będzie na opisanie sposobu realizacji poszczególnych komponentow, a także wybranego sposobu komunikacji z innymi komponentami. 7.4 Plan zapewnienia jakości Jeśli istnieje taka możliwość korzystamy tylko ze sprawdzonych standardów. Ustalamy jednolity styl pisanego kodu. Każda funkcja poszczególnego komponentu jest testowana. Nieoczywiste fragmenty kodu zawierają stosowny komentarz umożliwiający szybkie zrozumienie zasady działania (łatwość wychwycenia błędu i modyfikacji kodu). 7.5 Plan rozwiazywania problemów W razie wystąpienia problemu praca nad danym zagadnieniem jest wstrzymywana, osoba przechodzi do innych zadań, problem przedstawiany jest na najbliższym spotkaniu zespołu i wspólnie dyskutowany. Po przedstawieniu potencjalnych zalet i wad wybierane jest rozwiązanie w sposób demokratyczny. 7.6 Plan ulepszania Poszczególne moduły systemu przedstawiane potencjalnym użytkownikom. Zbierane są opinie na temat działających funkcjonalności. Użytkownicy proponują nowe funkcjonalności, których ich brakuje. Po wydaniu pierwszej oficjalnej wersji systemu planowane są wersje kolejne w postaci kompletnych systemów, wraz z uaktualnieniami wersji poprzednich (w skrajnych przypadkach uaktualnienie instaluje cały system zostawiając ustawienia i dane personalne użytkowników). 17
18 8 Historia zmian Data Osoba Opis zmian Łukasz Krupa Utworzono dokument Łukasz Krupa Rozwinięto podpunkty Grzegorz Łuczyna Wykonano analizę punktów funkcyjnych Sebastian Chojniak Wprowadzono plany procesów technicznych Łukasz Krupa Wstawiono diagram Gantta Grzegorz Łuczyna Wprowadzono zarządzanie projektem Sebastian Chojniak Wprowadzono plany pomocnicze Grzegorz Łuczyna Poprawiono diagram Gantta Sebastian Chojniak, Złożono dokument Łukasz Krupa, Grzegorz Łuczyna 18
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ółowoSoftware Development Plan
Software Development Plan Łukasz Bieniasz-Krzywiec Dariusz Leniowski Jakub Łącki 30 maja 2007 1 Spis treści 1 Wprowadzenie 4 1.1 Cel............................................. 4 1.2 Zakres...........................................
Bardziej szczegółowoPlan wykonania systemu ISOiWUT
Plan wykonania systemu ISOiWUT Michał Lewowski Piotr Skowron Piotr Wygocki Michał Matczuk 4 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoAskAnything 5.06.2006. Plan Przedsięwzięcia Plan Testów
AskAnything Plan Przedsięwzięcia Plan Testów Rzut oka na harmonogram Organizacja Rozwijanie aplikacji Zespół deweloperski 6 osób w zespole koordynator projektant i programista WWW projektant baz danych
Bardziej szczegółowoZespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP SDP
Zespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak Projekt SZOP SDP Spis treści 1 Wprowadzenie 3 1.1 Cel projektu..................................... 3 1.2 Założenia i zależności................................
Bardziej szczegółowoRubik s Manager - SAD
Rubik s Manager - SAD Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 16 maja 2007 1 Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................
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ółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
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ół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ół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ół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ółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoCykle życia systemu informatycznego
Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów
Bardziej szczegółowoPlan projektu. Robert Dyczkowski, Piotr Findeisen, Filip Grządkowski. 4 czerwca 2006
Robert Dyczkowski, Piotr Findeisen, Filip Grządkowski 4 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoMODELE 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ółowoNarzę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ół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ółowoTopór Światowida Software Architecture Document
Topór Światowida Software Architecture Document Maciej Pawlisz Łukasz Polak Oskar Skibski Jakub Światły 30 maja 2007r. 1 Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4
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ół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ółowoRUP. 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ółowoPRZEWODNIK 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ół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ółowoNazwa 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ółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoPodstawy 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ółowoPRZEWODNIK 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ół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ół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ółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: obowiązkowy w ramach specjalności: Programowanie aplikacji internetowych Rodzaj zajęć: laboratorium PRZEWODNIK PO PRZEDMIOCIE I KARTA PRZEDMIOTU
Bardziej szczegółowoIn ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania
In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i
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ółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoOPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA
OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoFeature 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ółowoWytwarzanie oprogramowania
AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia
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ół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ół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ółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoCo 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ółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoArchitektura oprogramowania w praktyce. Wydanie II.
Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?
Bardziej szczegółowoWykł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ół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ółowoKARTA 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ółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
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ółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt o implementacja pakietu gier planszowych realizowany na platformie Android Autor: Paweł Piechociński Promotor: dr Jadwiga Bakonyi Kategorie: gra planszowa
Bardziej szczegółowoEgzamin / 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ółowoE-ID1S-08-s5. Informatyka. I stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu E-ID1S-08-s5 Nazwa modułu Nazwa modułu w języku angielskim Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Podstawy Inżynierii Programowania
Bardziej szczegółowoZdalne monitorowanie i zarządzanie urządzeniami sieciowymi
Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania Rodzaj zajęć: laboratorium PROJEKT ZESPOŁOWY DYPLOMOWY IO Team Project SE Forma studiów:
Bardziej szczegółowoSylabus KRK. Sprawne zarządzanie jakością kształcenia. Elastyczna organizacja programów studiów zgodnie z Krajowymi Ramami Kwalifikacji
2013 Sylabus KRK Sprawne zarządzanie jakością kształcenia. Elastyczna organizacja programów studiów zgodnie z Krajowymi Ramami Kwalifikacji Autonomia programowa uczelni w praktyce: spójność programów z
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoRubik s Manager. Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna. 13 marca 2007
Rubik s Manager Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 13 marca 2007 1 Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................
Bardziej szczegółowoZarzą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ółowoPROGRAM PRAKTYKI ZAWODOWEJ. Technikum Zawód: technik informatyk
PROGRAM PRAKTYKI ZAWODOWEJ Technikum Zawód: technik informatyk 351203 Lp. Temat 1 Zajęcia wprowadzające. Zapoznanie z zakładem, regulaminem pracy, przepisami BHP oraz instruktaż bhp. 2 Montaż i eksploatacja
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoI. 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ółowoCzęść 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ół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ółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoSzczegółowy opis przedmiotu zamówienia- założenia do metodyki realizacji przedmiotu zamówienia
Załącznik nr 2 Szczegółowy opis przedmiotu zamówienia- założenia do metodyki realizacji przedmiotu zamówienia W niniejszym załączniku do SIWZ Zamawiający zawarł wymagania i założenia jakie musi przyjąć
Bardziej szczegółowoPracowania Projektowania Zespołowego
Pracowania Projektowania Zespołowego 1. ZałoŜenia co do prowadzenia projektów: a/ Spotkania w ramach grupy projektowej: KaŜda grupa spotyka się raz w tygodniu Na spotkaniach mają być omówione następujące
Bardziej szczegółowoZarządzanie projektami IT
Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie
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ółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
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ółowoSVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1
SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2
Bardziej szczegółowoInż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ółowoProjektowanie 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ół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ół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ółowoWybór ZSI. Zakup standardowego systemu. System pisany na zamówienie
Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę
Bardziej szczegółowoProgram szkolenia: Continuous Integration i Git
Program szkolenia: Continuous Integration i Git Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Continuous Integration i Git tools-git-ci Narzędzia developerzy testerzy 2 dni 50%
Bardziej szczegółowoE-1IZ3-06-s6. Inżynieria Programowania. Informatyka. I stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu E-1IZ3-06-s6 Nazwa modułu Inżynieria Programowania Nazwa modułu w języku angielskim Software Engineering Obowiązuje od roku akademickiego 2012/2013 (aktualizacja
Bardziej szczegółowoProjekty zespołowe. - biznesowy z analizą strategiczną - przedsięwzięcia: opis ogólny produktu. 2. Zakres
Projekty zespołowe 1. Warunki wstępne 1. Studenci wykonują projekty w zespołach 5-7 os., każdy zespół ma inny temat 2. Każdy zespół pracuje zgodnie z wybraną/przydzieloną metodyką (np. Prince, Scrum, TenStep,
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Inżynieria Biomedyczna Rodzaj przedmiotu: obowiązkowy moduł specjalności informatyka medyczna Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE INTERNETOWE Internet Programming
Bardziej szczegółowoSoftware Development Plan dla systemu USOSweb 2.0
Software Development Plan dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 4 czerwca 2007 1 Spis treści 1 Wprowadzenie 4 1.1 Cel..........................................
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ółowoWprowadzenie do systemów informacyjnych
Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj
Bardziej szczegółowoProjektowanie interakcji
Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director
Bardziej szczegółowoOrganizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią
Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje
Bardziej szczegółowoZapewnij 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ółowoWskazó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ółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoZagadnienia egzaminacyjne INFORMATYKA. stacjonarne. I-go stopnia. (INT) Inżynieria internetowa STOPIEŃ STUDIÓW TYP STUDIÓW SPECJALNOŚĆ
(INT) Inżynieria internetowa 1.Tryby komunikacji między procesami w standardzie Message Passing Interface. 2. HTML DOM i XHTML cel i charakterystyka. 3. Asynchroniczna komunikacja serwerem HTTP w technologii
Bardziej szczegółowoDokumentacja projektu QUAIKE Architektura oprogramowania
Licencjacka Pracownia Oprogramowania Instytut Informatyki Uniwersytetu Wrocławskiego Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, Bartłomiej Gałkowski Dokumentacja projektu QUAIKE Architektura
Bardziej szczegółowoWARUNKI REALIZACJI GIMNAZJALNEGO PROJEKTU EDUKACYJNEGO
I. 1. Uczniowie PGS Nr 11w Wałbrzychu biorą udział w realizacji projektu edukacyjnego. 2. Projekt edukacyjny jest zespołowym, planowym działaniem uczniów, mającym na celu rozwiązanie konkretnego problemu,
Bardziej szczegółowoProcedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje:
1. Niniejsza Procedura odbioru obejmuje: Załącznik nr 3 do Umowy nr... z dnia... zmodyfikowany w dniu 18.05.2015 r. Procedura Odbioru a) proces uzgadniania wykazu Produktów do odbioru; b) proces uzgadniania
Bardziej szczegółowoSzczegółowy opis przedmiotu zamówienia założenia dla metodyki realizacji Projektu
Załącznik nr 2 do SIWZ Szczegółowy opis przedmiotu zamówienia założenia dla metodyki realizacji Projektu W niniejszym załączniku do SIWZ Zamawiający zawarł wymagania i założenia jakie musi przyjąć Wykonawca
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Inżynieria Biomedyczna Rodzaj przedmiotu: obowiązkowy moduł specjalności informatyka medyczna Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE OBIEKTOWE Object-Oriented Programming
Bardziej szczegółowo