Konkurs inżynierii wymagań RE-Challenge 15 maja 2015

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

Download "Konkurs inżynierii wymagań RE-Challenge 15 maja 2015"

Transkrypt

1 Konkurs inżynierii wymagań RE-Challenge 15 maja 2015 re-challenge.pl wymagania.org.pl 1. Krzywa Boehm a A. Wynika z niej, że trudne wymagania należy zdefiniować jak najwcześniej B. Jest decydującym argumentem na rzecz nieopłacalności zmiany wymagań w późniejszych etapach projektu C. Wskazuje na względny wzrost kosztu zmiany wymagań lub implementacji w czasie (im później, tym drożej) D. Dotyczy wyłącznie zagadnień związanych z testowaniem i nie jest interesująca w kontekście inżynierii wymagań 2. Co to są wymagania poza-funkcjonalne? (popularniejsza nazwa: niefunkcjonalne)? Wybierz jedną, najlepszą odpowiedź A. To są wymagania, określające działanie systemu poza typowymi warunkami działania B. Wymagania o niższym priorytecie (nieobowiązkowe) C. Wymagania dotyczące różnych charakterystyk działania systemu D. Wymagania wysokopoziomowe (ogólne, biznesowe) 3. Proszę wybrać dwa spośród poniższych stwierdzeń, które są prawdziwe ( prawdziwe, czyli zgodne z często przyjętymi definicjami) A. Wymaganie określa różnicę między stanem obecnym, a przyszłym stanem pożądanym B. Wymaganie, to sekwencja kroków procesowych, wymaganych do realizacji określonej potrzeby biznesowej klienta C. Wymaganie, to jedna z funkcjonalności planowanego systemu IT D. Wymaganie, to zidentyfikowany problem biznesowy, wymagający usunięcia lub optymalizacji E. Wymaganie, to na przykład, cechy systemu z punktu widzenia jego operatorów/użytkowników 4. Klient domaga się od dostawcy systemu IT, między innymi, realizacji wymagań, podanych a punktach A DE poniżej. Które dwa spośród tych wymagań odnoszą się do budowanego systemu? A. Dostawca odpowie na żądanie zmiany w ciągu pięciu dni B. Raporty testowe testów integracyjnych mają być udostępnione do przeglądu, a raport testu systemowego ma być przekazany w oryginale C. System musi mieć przepustowość 100 transakcji na sekundę w każdej sytuacji i czasie D. Narzędzie Subversion ma być stosowane do zarządzania konfiguracją E. Przy normalnym obciążeniu, czas odpowiedzi nie może przekraczać dwóch sekund w co najmniej 90 procentach przypadków 5. Koszty zmiany implementacji błędnych wymagań są tym wyższe, im później w projekcie się je dokonuje. Dlaczego wobec tego metody agile, zakładające możliwość takich zmian, mają uzasadnienie? A. Ponieważ postulują, że aspekt kosztowy jest mniej ważny, niż szybkość realizacji systemu B. Ponieważ ważniejsze od kosztów zmian jest zapewnienie uczestnikom projektu dobrej atmosfery pracy oraz metod skutecznej komunikacji C. Ponieważ często koszt i czas usiłowania określenia wszystkich wymagań z góry przewyższa koszt ich ewentualnych, późnych zmian D. Ponieważ agile ma zastosowanie wyłącznie wobec systemów, dla których koszty zmian są względnie niskie 6. Co wiele norm nazywa kontekstem systemu? A. Czynniki, od których zależą możliwe konfiguracje i warianty systemu B. Interesariuszy systemu C. Wszystko, co znajduje się poza granicami systemu D. Zbiór czynników, które trzeba wziąć pod uwagę przy określaniu wymagań Strona 1 z 12 Strona 2 z 12

2 7. Wybierz jedno (jedyne) nieprawdziwe twierdzenie: A. Użytkownik systemu jest interesariuszem systemu B. Nieistotny interesariusz systemu jest poza kontekstem systemu C. Tak zwana granica systemu określa, którzy użytkownicy znajdują się poza kontekstem systemu D. Potrzeby klienta / zleceniodawcy to tylko część wymagań wobec systemu [1 punkt] 8. W procesie inżynierii wymagań dla systemu bazodanowego stwierdzono, że prawa dotyczące ochrony danych nie dotyczą tego systemu, ponieważ przetwarzane dane są anonimowe. Na co wpływa to stwierdzenie? A. Granicę systemu B. Granicę kontekstu C. Interfejsy systemu D. Tak zwaną szarą strefę granicy systemu [Wyjaśnienie: szara strefa granicy systemu to obszar, co do którego są wątpliwości, czy ma należeć do systemu, czy nie] 9. Uzupełnij następujące zdanie... może w każdej chwili zmienić priorytet elementów w rejestrze [ang. backlog]... A. Właściciel produktu przebieg(u) B. Zespół Scrum produkt(u) C. Właściciel produktu produkt(u) D. Scrum Master przebieg(u) 10. Wskaż jedno nieprawdziwe twierdzenie A. Inżynieria wymagań nie obejmuje metod analizy i modelowania wymagań B. Inżynieria wymagań jest częścią inżynierii oprogramowania C. Inżynieria oprogramowania jest częścią inżynierii systemów D. Inżynieria wymaganiami opisuje techniki pozyskiwania wymagań [1 punkt] 11. Uzupełnij następujące zdanie Podczas pierwszej części spotkania planistycznego przebiegu [sprint planning meeting] tworzy się..., a podczas drugiej części tego spotkania tworzy się... A. Rejestr przebiegu [sprint backlog] - listę zadań [task list] B. Rejestr produktu [product backlog] listę zadań [task list] C. Cel przebiegu [spring goal] rejestr przebiegu [sprint backlog] D. Rejestr produktu rejestr przebiegu 12. Wybierz nieprawdziwe zdanie A. Modele sekwencyjne zakładają następowanie faz projektu jedna po drugiej B. Modele zwinne są formą szybszej realizacji modelu kaskadowego C. Model kaskadowy i model V są sekwencyjne D. Modele zwinne to rodzaje modelu iteracyjnego 13. Właściciel produktu odpowiada za to, CO ma być zbudowane (a nie JAK). Za co odpowiada ScrumMaster? A. JAK należy zbudować produkt B. Jak stosuje się różne narzędzia Agile Scrum, takie jak np. poker planistyczny, codzienne spotkania scrumowe, itp. C. Wyniki pracy D. Zadowolenie członków zespołu scrumowego podczas przebiegu 14. Wybierz typową kolejność faz procesu inżynierii wymagań A. Konsolidacja - identyfikacja - analiza - specyfikacja - zarządzanie zmianami walidacja B. Walidacja - identyfikacja - analiza - specyfikacja konsolidacja - zarządzanie zmianami C. Identyfikacja - zarządzanie zmianami - analiza - specyfikacja konsolidacja - walidacja D. Identyfikacja - analiza - specyfikacja konsolidacja - zarządzanie zmianami walidacja 15. Co nie należy do rejestru produktu? [product backlog] Strona 3 z 12 Strona 4 z 12

3 1. Szczegółowe zadania 2. Powtarzające się wydarzenia, takie jak codzienny Scrum 3. Opowieści użytkowników 4. Czynności związane z uzupełnianiem wymagań 5. Czynności administracyjne A. Żaden z tych elementów nie jest częścią rejestru produktu B. 1, 2, 5 C. 3 D. 2, 3, 4 E. 1, 2, 4, Co to jest rejestr produktu? [product backlog] A. Lista możliwych, przyszłych zadań dla zespoły scrumowego B. Lista spóźnionych zadań C. Lista wymagań wysokopoziomowych oraz opowieści użytkowników [user stories] do zrealizowania w trakcie projektu D. Zestaw kamieni milowych projektu E. Zadania, które mają być rozwiązane w czasie przebiegu 17. Kto z podanych niżej osób nie jest interesariuszem systemu? A. Aktorzy przypadków użycia, które system obsługuje B. Osoby, mieszkające w pobliżu serwerowni, obsługującej bazę danych systemu C. Klienci użytkowników systemu D. Osoby, zamieszkałe w pobliżu elektrowni atomowej, sterowanej przez wbudowany system informatyczny 18. Czym różni się inżynieria wymagań od analizy biznesowej? A. Najpierw określa się wymagania, a potem analizuje zadania biznesowe B. Analiza biznesowa pozwala określić słabe punkty procesu, a inżynieria wymagań modeluje nowy, lepszy proces C. Wynikiem analizy jest opis procesu, a inżynierii wymagań - opis cech i funkcji systemu IT, wspierającego proces D. Inżynieria wymagań jest działem informatyki, zaś analiza biznesowa - działem ekonomiki przedsiębiorstwa 19. Jakie są korzyści z oznaczania wymagań unikalnymi identyfikatorami? A. Ułatwiają oszacowanie wielkości implementacji B. Stanowią jednoznaczną podstawę komunikacji C. Ułatwiają śledzenie związków wymagań między sobą D. Ułatwiają śledzenie związków wymagań z innymi artefaktami procesu informatycznego 20. Specjalista inżynierii wymagań, to: [3 odpowiedzi, 1 punkt] A. Osoba o szerokich horyzontach i bogatych zainteresowaniach B. Osoba mająca ogromne doświadczenie biznesowe w dziedzinie, której działanie ma usprawnić system C. Osoba niezwykle komunikatywna, umiejąca zarażać innych entuzjazmem D. Osoba, która potrafi skutecznie pośredniczyć między klientem a projektem IT 21. Jakie są korzyści ze śledzenia powiązań wymagań? [requirements traceability] A. Ułatwia wykonywanie analizy wpływu w procesie zarządzania zmianami B. Ułatwia weryfikację szczegółów implementacji C. Ułatwia automatyczny eksport danych z narzędzia do zarządzania wymaganiami D. Ułatwia identyfikację źródeł wymagań 22. Jaka jest relacja między kontraktem prawnym, a inżynierią wymagań? A. Kontrakt zakłada maksymalną zmienność wstępnych wymagań B. Kontrakt powinien określać, w jaki sposób zweryfikuje się zrealizowanie wymagań C. Kontrakt dotyczący projektów realizowanych metodami zwinnymi, powinien tak samo, jak wymagania, podlegać częstym modyfikacjom D. Norma ISO/IEEE określa wzorzec kontraktu Strona 5 z 12 Strona 6 z 12

4 23. Co dobrego dla inżynierii wymagań zrobił Edsger Dijkstra? A. Wymyślił analizę obiektową i obiektowe języki programowania B. Jest autorem analizy strukturalnej i projektowania strukturalnego C. Tworząc strukturalne języki programowania, spowodował, że inżynieria wymagań stała się znacznie łatwiejsza dzięki powtarzalnym algorytmom D. Tworząc strukturalne języki programowania, spowodował, że mniej uwagi trzeba poświęcać na kodowanie, a więcej - na wymagania 24. Jakie właściwości ma rejestr produktu? 1. Jego wszystkie element mają wartość dla klienta 2. Jego elementy są uporządkowane według priorytetów 3. Pozycja elementu rejestru zależy od tego, jak szczegółowo jest już opisany 4. Elementy rejestru są oszacowane pod kątem pracochłonności 5. Jest to zmieniający się, żywy dokument 6. Nie ma w nim żadnych zadań do wykonania ani innych niskopoziomowych czynności A. 1, 2, 3, 4, 5, 6 B. 1, 3, 4, 5, 6 C. 2, 3, 4, 5, 6 D. 1, 2, 3, 4, 5 E. 1, 2, Wizja projektu, to: A. Dokument, szkicowo przedstawiający biznesowe uzasadnienie i zakres projektu B. Specyfikacja wymagań systemu oraz harmonogram wdrożenia projektu C. Dokument, najczęściej tworzony przez dział marketingu firmy klienta D. Analiza ryzyka biznesowego związanego z planowanym systemem 26. Jakie są najważniejszekorzyści stosowania formalnych modeli (np. BPMN, przypadków użycia) do opisu wymagań? A. Modele nie zawierają nadmiarowej informacji słownej, więc można je zrozumieć znacznie szybciej, niż tekst B. Modele umożliwiają znacznie bardziej całościowy opis systemu C. Modele można zweryfikować pod kątem zgodności z formalną składnią D. Modele tworzy się przy pomocy narzędzi, dzięki czemu łatwiej jest przy ich pomocy zarządzać wymaganiami E. Niektóre narzędzia umożliwiają generowanie kodu źródłowego wprost z modelu 27. Jaki jest związek architektury korporacyjnej z analizą biznesową? A. Zdefiniowanie architektury korporacyjnej powinno być poprzedzone analizą biznesową procesów B. Nie ma między nimi żadnego związku: analiza określa cele biznesowe, zaś architektura - organizację C. Architektura korporacyjna wynika z wybranej architektury IT D. Analiza biznesowa służy do określenia, jaka architektura korporacyjna najlepiej realizuje cele CRM 28. Który z punktów poniżej jest listą wyłącznie technik pozyskiwania wymagań? A. Burza mózgów, obserwacja polowa, terminowanie, obiektowość B. Kwestionariusze (ankiety), wywiady, samo-rejestracja C. Reprezentant klienta w zespole, modelowanie formalne D. Na podstawie istniejących dokumentów, ponowne wykorzystanie kodu źródłowego 29. Jakie kryteria powinien uwzględnić właściciel produktu, aby określić wstępnie priorytety elementów rejestru produktu? 1. Korzyść biznesową 2. Zwrot z inwestycji (ROI) 3. Model Kano, projektowanie zorientowane na użytkownika oraz narzędzie wspomagające podejmowanie decyzji 4. Poziom ryzyka 5. Przewidywaną złożoność implementacji A. Wszystkie kryteria 1-5 B. 1, 2 C. 1, 2, 3, 4 D. 5 E. 2 Strona 7 z 12 Strona 8 z 12

5 30. Które z poniższych twierdzeń na temat specyfikacji wymagań jest prawdziwe? A. Opowieści użytkowników, to jeden ze sposobów zapisu specyfikacji wymagań B. Specyfikację wymagań klienta robi analityk, specyfikację systemu (rozwiązania) robi klient C. Specyfikacja wymagań rozwiązania nie jest przeznaczona dla zespołu programistycznego D. Specyfikacja oprogramowania nie może być specyfikacją rozwiązania 31. Czego nie da się opisać przy pomocy diagramu przypadków użycia? A. Kroków wykonywanych podczas realizacji przypadków użycia B. Aktorów (użytkowników) systemu C. Funkcji, wykonywanych przez opisywany system D. Granicy między systemem a jego otoczeniem E. Powiązań między użytkownikami a funkcjami systemu ( kto wykorzystuje co ) 32. Do czego nie wykorzystuje się diagramów BPMN? A. Do opisu procedur (scenariuszy) przypadków użycia B. Do rozróżniania czynności wykonywanych ręcznie i automatycznie w procesie biznesowym C. Do analizy wariantów architektury systemu IT wspierającego proces biznesowy D. Do analizy możliwych usprawnień procesu wykonywanego bez wsparcia IT E. Do określania kryteriów zarządzania produktami 33. Koszty błędnych wymagań (uwaga podstępne sformułowania poniżej!) A. Są niewielkie, bo wymagania nietrudno naprawić B. Są bardzo wysokie, bo powodują błędy w kodzie oprogramowania C. Ich koszt jest tym mniejszy, im wcześniej zostaną wykryte i naprawione D. Błędy wymagań są szczególnie kosztowne, bowiem ich wykrywanie jest czasochłonne (np. przez inspekcje) 34. W trakcie trwania przebiegu, właściciel produktu odkrywa nowe, ważne opowieści użytkowników. Co powinien teraz zrobić? A. Nic B. Przerwać przebieg i rozpocząć pracę na tymi opowieściami C. Dodać nowe opowieści do rejestru produktu D. Polecić zespołowi implementację tych opowieści w czasie trwającego przebiegu E. Poinformować klienta, że implementacja tych niezaplanowanych opowieści jest niemożliwa 35. Poniższe zdania określają związek między UML a inżynierią wymagań. Wskaż prawdziwe zdanie A. Modele UML służą przede wszystkim do projektowania architektury systemu i jego danych, a nie do opisu wymagań B. Powstanie UML w latach 90-ych ubiegłego wieku spowodowało wyodrębnienie się inżynierii wymagań z analizy biznesowej, jako odrębnej dyscypliny C. Modele UML wspierają inżynierię wymagań dzięki temu, że stanowią jednolity, obszerny zestaw różnych technik modelowania D. Modele UML umożliwiają tworzenie kodu wprost z wymagań, z pominięciem etapów pośredniczących 36. Metoda szerokopasmowa delficka (ang. wideband delphi) szacowania pracochłonności na podstawie wymagań, to: A. Sposób na zwiększenie produktywności i szybkości zespołów wykonujących takie oszacowania B. Jej teoretycznym podłożem jest psychologiczna teoria rezonansu morficznego C. Forma organizacji pracy zespołu ekspertów, mająca na celu zwiększenie trafności oceny D. Formalny algorytm wyprowadzania przewidywanej liczby linii kodu aplikacji z modelu wymagań 37. Właściciel produktu dowiaduje się od klienta, że zmieniły się założenia biznesowe i niektóre wymagania nie będą już potrzebne. Co powinien zrobić? A. Nic B. Obniżyć priorytety tych wymagań i przenieść je na koniec rejestru produktu C. Usunąć te wymagania z rejestru produktu D. Poinformować klienta, że zbyt późno jest na zmiany i że wymagania zostaną i tak zrealizowane E. Poinformować przełożonych, że klient nie wie, czego chce Strona 9 z 12 Strona 10 z 12

6 38. Jakie są korzyści z wykorzystania wzorców zdań (sentence templates), jeśli wymagania opisuje się w języku naturalnym? A. Od samego początku unika się niektórych błędów w formułowaniu wymagań B. Zastosowanie wzorców zdań gwarantuje brak niejednoznacznej terminologii C. Nauczenie się korzystania z wzorców zdań jest szybsze, niż pisanie wymagań w języku bez użycia takich wzorców D. Wzorce pozwalają zawrzeć w wymaganiach więcej treści E. Wymagania zapisane według wzorca zdań automatycznie spełniają niektóre kryteria jakości dla wymagań 42. Jakie wymagania, dla kogo? Proszę wybrać dwa prawdziwe stwierdzenia A. Dla testerów jest ważne, aby wymagania były możliwe do zaimplementowania B. Dla programistów jest ważne, aby wymagania dawały się łatwo zmieniać C. Dla wszystkich jest ważne, aby wymagania były spójne D. Dla kierownictwa jest ważne, aby wymagania miały określone priorytety E. Dla administratorów systemu, realizującego wymagania, jest ważna ich szczegółowość. 39. Co oznacza testowanie na podstawie wymagań? A. Każde testowanie musi odbywać się na podstawie spisanych wymagań, bez nich mija się z celem B. Oznacza to przede wszystkim pomiar pokrycia wymagań testami C. Spisane wymagania służą zarówno jako źródło wiedzy, jakie są poprawne, oczekiwane wyniki wielu testów, jak i pozwalają wstępnie określić zakres testów D. Automatyczne generowanie przypadków testowych z formalnego modelu wymagań 40. Scrum Master informuje właściciela produktu, że zespół scrum ma do niego wiele pytań, ale trudno im się z nim skontaktować. Co powinien zrobić właściciel produktu? A. Nic B. Przekazać sprawę wyżej, do zespołu zarządzającego projektem C. Zorganizować spotkania, pozwalające na regularne wyjaśnienie wątpliwości D. Wysłać do zespołu i poprosić ich o informację, jakie mają wątpliwości E. Przerwać przebieg, wyjaśnić wątpliwości i rozpocząć nowy przebieg 41. Który z poniższych warunków oznacza, że sekwencyjny (np. kaskadowy) model działania zapewne nie będzie odpowiedni? A. Wymagania są stabilne, biznes niezmienny B. Wymagań jest niewiele C. Regulacje prawne określają, że specyfikacja wymagań musi być ukończona i zaakceptowana przed rozpoczęciem projektu D. Proces biznesowy jest w trakcie tworzenia i często się zmienia Strona 11 z 12 Strona 12 z 12

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

Opisy szkoleń dla certyfikatów Agile Scrum. www.cts.com.pl

Opisy szkoleń dla certyfikatów Agile Scrum. www.cts.com.pl Opisy szkoleń dla certyfikatów Agile Scrum www.cts.com.pl SPIS TREŚCI Opisy szkoleń dla certyfikatów Agile Scrum...2 Istniejące certyfikacje agile...2 Szkolenia oferowane przez CTS...3 Agile Tester (zgodne

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

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

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec

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

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

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

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

INŻYNIERIA OPROGRAMOWANIA

INŻYNIERIA OPROGRAMOWANIA INSTYTUT INFORMATYKI STOSOWANEJ 2013 INŻYNIERIA OPROGRAMOWANIA Inżynieria Oprogramowania Proces ukierunkowany na wytworzenie oprogramowania Jak? Kto? Kiedy? Co? W jaki sposób? Metodyka Zespół Narzędzia

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

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

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

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

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

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

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank. Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności

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

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

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

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

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Projektowanie interakcji

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

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

Szybkość w biznesie. Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015

Szybkość w biznesie. Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015 Szybkość w biznesie Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015 Klient Wykonawca...wprowadzamy nowy typ przelewów do aplikacji internetowej. Dodam

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

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

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

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

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

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

Bardziej szczegółowo

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

Projektowanie systemów informatycznych. wykład 6

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

Tester oprogramowania 2014/15 Tematy prac dyplomowych

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

firmy produkty intranet handel B2B projekty raporty notatki

firmy produkty intranet handel B2B projekty raporty notatki firmy mail intranet produkty DOKUMENTY handel raporty B2B projekty notatki serwis zadania Dlaczego warto wybrać Pakiet ITCube? Najczęściej wybierany polski CRM Pakiet ITCube jest wykorzystywany przez ponad

Bardziej szczegółowo

Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka

Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka Test kwalifikacyjny obejmuje weryfikację efektów kształcenia oznaczonych kolorem szarym, efektów: K_W4 (!), K_W11-12, K_W15-16,

Bardziej szczegółowo

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla

Bardziej szczegółowo

Dokument Detaliczny Projektu

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

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

Optymalizacja Automatycznych Testów Regresywnych

Optymalizacja Automatycznych Testów Regresywnych Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis

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

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

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

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.

Bardziej szczegółowo

Tom 6 Opis oprogramowania

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Pryncypia architektury korporacyjnej

Pryncypia architektury korporacyjnej Pryncypia architektury korporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl Plan prezentacji Czym

Bardziej szczegółowo

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl Szkolenia zgodne z sylabusem www.cts.com.pl DLACZEGO WARTO PRZYJŚĆ NA DO CERTYFIKATU? Aby dostarczyć klientom potrzebną jakość, konieczne jest testowanie produktów informatycznych. O największych awariach,

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi

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

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

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

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

Bardziej szczegółowo

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

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

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie

Bardziej szczegółowo

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM Hubert Wawrzyniak Grupa Allegro PLAN PREZENTACJI 1. Projektowanie zorientowane na użytkownika 2. Model kaskadowy 3. Metodyka scrum 4. UCD w scrumie

Bardziej szczegółowo

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie Wykład 2 MIS-1-505-n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1 Agenda 1 2 3 4 5 6 2.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować

Bardziej szczegółowo

NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Jak usprawnić pracę w zespole IT? Wykorzystanie narzędzi do pracy grupowej na przykładzie zespołu Polska.pl Agnieszka Kukałowicz-Kolaszyńska, Starszy Specjalista IT

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

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

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie

Bardziej szczegółowo

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B.

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B. W zawiązku z otrzymaniem dofinansowania na projekt: Zautomatyzowany system B2B elektronicznej wymiany dokumentów i danych, realizowany w ramach Programu Operacyjnego Innowacyjna Gospodarka, Działanie 8.2:Wspieranie

Bardziej szczegółowo

Cykle życia systemu informatycznego

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

Karta Prezentacji Projektu

Karta Prezentacji Projektu Karta Prezentacji Projektu Karta Prezentacji Projektu powinna być uzupełniona z perspektywy osoby będącej uczestnikiem projektu bądź liderem projektu. Nazwa projektu: Usprawnienie procesu udzielenia kredytu

Bardziej szczegółowo

Plan zarządzania projektem

Plan zarządzania projektem Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty

Bardziej szczegółowo

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie 2. Jaki wpływ na ludzi, komunikację

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

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

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE OFERTA WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE W TWORZENIU MODELU AS-IS /Jest to przykład (wzór) oferty treść jest wypełniana na podstawie nie zobowiązujących rozmów i spotkań z Klientem, pracownikami

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

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

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:

Bardziej szczegół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

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

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

Analityk i współczesna analiza

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

Przedsięwzięcia Informatyczne w Zarządzaniu

Przedsięwzięcia Informatyczne w Zarządzaniu Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,

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

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

Bardziej szczegółowo

Tom 6 Opis oprogramowania

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

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

Bardziej szczegółowo

Udane wdrożenie systemu IT

Udane wdrożenie systemu IT Udane wdrożenie systemu IT Maciej Guzek CMMS Department Marketing & Sales Manager mguzek@aiut.com.pl To nie takie proste Czego klient potrzebował Co klient zamówił Co zrozumiał analityk Co opisywał projekt

Bardziej szczegółowo

Overlord - Software Development Plan

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

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów

Bardziej szczegółowo

Dokument Detaliczny Projektu

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

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) 1. Wstęp: 1.1. Cel. Niniejszy dokument przestawia specyfikację wymagań systemowych (zarówno funkcjonalnych jak i niefunkcjonalnych)

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

Modelowanie i analiza systemów informatycznych Spis treści

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

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo