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

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego

Bardziej szczegółowo

Analiza biznesowa a metody agile owe

Analiza biznesowa a metody agile owe Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania

Bardziej szczegółowo

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

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

Bardziej szczegółowo

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

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

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

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

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Extreme programming Główne założenia XP Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Praktyki Planowanie: Planowanie releasu Planowanie iteracji

Bardziej szczegółowo

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

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

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 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 x 1 2. Jaki wpływ na ludzi, komunikację

Bardziej szczegółowo

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

Usługa: Audyt kodu źródłowego Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności

Bardziej szczegółowo

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

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

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik Projektowanie oprogramowania Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik Agenda Weryfikacja i zatwierdzanie Testowanie oprogramowania Zarządzanie Zarządzanie personelem

Bardziej szczegółowo

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Błę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ółowo

Testowanie i walidacja oprogramowania

Testowanie i walidacja oprogramowania i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja

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

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

Praktyka testowania dla początkujących testerów

Praktyka testowania dla początkujących testerów Praktyka testowania dla początkujących testerów Warsztaty stanowią 100% praktykę testowania i skupiają się zwłaszcza na tych aspektach, które przydatne są w codziennej pracy testera. Przeznaczone są dla

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

Etapy życia oprogramowania

Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza

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

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

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 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. x 3 2. Jaki wpływ na ludzi, komunikację

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

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

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

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

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

Bardziej szczegółowo

Usługa: Testowanie wydajności oprogramowania

Usługa: Testowanie wydajności oprogramowania Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:

Bardziej szczegółowo

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

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna

Bardziej szczegółowo

Jak opisać wymagania zamawiającego wybrane elementy

Jak opisać wymagania zamawiającego wybrane elementy Jak opisać wymagania zamawiającego wybrane elementy Adam Rzeźnicki, Grzegorz Sobolewski PIIT Listopad, 2012 Agenda Kontekst ma znaczenie - na przykładzie cyklu wytwórczego systemu aplikacyjnego Rodzaje

Bardziej szczegółowo

Programowanie Zespołowe

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej.

Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej. Efekty dla studiów pierwszego stopnia profil ogólnoakademicki na kierunku Informatyka w języku polskim i w języku angielskim (Computer Science) na Wydziale Matematyki i Nauk Informacyjnych, gdzie: * Odniesienie-

Bardziej szczegółowo

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

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

Zwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow)

Zwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow) Program szkolenia: Zwinna współpraca programistów i testerów z wykorzystaniem BDD i Spec Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Zwinna współpraca programistów i testerów

Bardziej szczegółowo

Informatyczne fundamenty

Informatyczne fundamenty Informatyczne fundamenty Informatyka to szeroka dziedzina wiedzy i praktycznych umiejętności. Na naszych studiach zapewniamy solidną podstawę kształcenia dla profesjonalnego inżyniera IT. Bez względu na

Bardziej szczegółowo

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC Jarosław Świerczek Punkty funkcyjne Punkt funkcyjny to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie

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

Podstawy modelowania programów Kod przedmiotu

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

Inżynieria oprogramowania II

Inżynieria oprogramowania II Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś

Bardziej szczegółowo

Opis metodyki i procesu produkcji oprogramowania

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

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

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

Bardziej szczegółowo

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Agenda Metafory o Zwinności i Sztywności Teza: Oszukujemy się co do sukcesów projektów Agile Objawy chaosu w projektach

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

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

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu

Bardziej szczegółowo

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

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

SCRUM Product Owner - wstęp do zarządzania produktami

SCRUM Product Owner - wstęp do zarządzania produktami SCRUM Product Owner - wstęp do zarządzania produktami Oferta szkolenia Kontakt: Tomasz Tomaszewski t.tomaszewski@productvision.pl 505 448 703 PRODUCT VISION Wierzymy, że innowacyjne produkty technologiczne

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

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

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof

Bardziej szczegółowo

Efekty kształcenia dla kierunku studiów INFORMATYKA, Absolwent studiów I stopnia kierunku Informatyka WIEDZA

Efekty kształcenia dla kierunku studiów INFORMATYKA, Absolwent studiów I stopnia kierunku Informatyka WIEDZA Symbol Efekty kształcenia dla kierunku studiów INFORMATYKA, specjalność: 1) Sieciowe systemy informatyczne. 2) Bazy danych Absolwent studiów I stopnia kierunku Informatyka WIEDZA Ma wiedzę z matematyki

Bardziej szczegółowo

Łatwa czy niełatwa droga do celu? - wdrożenie COSMIC w ZUS

Łatwa czy niełatwa droga do celu? - wdrożenie COSMIC w ZUS - wdrożenie COSMIC w ZUS Warszawa, 07.06.2017 Dlaczego w ZUS zdecydowano się na wdrożenie wymiarowanie złożoności oprogramowania akurat metodą COSMIC? jest metodą najbardziej transparentną i ograniczającą

Bardziej szczegółowo

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

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

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

Akademia testera oprogramowania i systemów IT Poziom I specjalista testowania (56 h) kurs dzienny

Akademia testera oprogramowania i systemów IT Poziom I specjalista testowania (56 h) kurs dzienny K U R S Z A W O D O W Y Akademia testera oprogramowania i systemów IT Poziom I specjalista testowania (56 h) kurs dzienny MIEJSCE I TERMIN: Warszawa, 1 3 marca 2017 r. Terminy szczegółowe: Sesja A, 1 3

Bardziej szczegółowo

Pytania z przedmiotów kierunkowych

Pytania z przedmiotów kierunkowych Pytania na egzamin dyplomowy z przedmiotów realizowanych przez pracowników IIwZ studia stacjonarne I stopnia Zarządzanie i Inżynieria Produkcji Pytania z przedmiotów kierunkowych 1. Co to jest algorytm?

Bardziej szczegółowo

Nieprawidłowości w wymiarowaniu punktami funkcyjnymi

Nieprawidłowości w wymiarowaniu punktami funkcyjnymi Nieprawidłowości w wymiarowaniu punktami funkcyjnymi przyczyny, konsekwencje i zapobieganie Jarosław Świerczek Członek COSMIC International Advisory Council, przedstawiciel na Polskę Członek Polskiego

Bardziej szczegółowo

Projektowanie BAZY DANYCH

Projektowanie BAZY DANYCH Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

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

Wszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.

Wszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k. Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym

Bardziej szczegółowo

Oceny z prezentacji INKU011S. Zofia Kruczkiewicz

Oceny z prezentacji INKU011S. Zofia Kruczkiewicz Oceny z prezentacji INKU011S Zofia Kruczkiewicz Data Student Oceny Uwagi 22.10.2017 231085 3.0 Przedstaw idealne środowisko do stosowania inżynierii oprogramowania- opisz elementy tego środowiska (sprzęt

Bardziej szczegółowo

KARTA PRZEDMIOTU. Projektowanie systemów czasu rzeczywistego D1_13

KARTA PRZEDMIOTU. Projektowanie systemów czasu rzeczywistego D1_13 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom : Profil : Forma studiów: Obszar : Dziedzina:

Bardziej szczegółowo

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary

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

Międzynarodowa Rada Inżynierii Wymagań. The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS.

Międzynarodowa Rada Inżynierii Wymagań. The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS. Międzynarodowa Rada Inżynierii Wymagań The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS www.cts.com.pl MISJA IREB Misją IREB jest udoskonalenie praktyki inżynierii wymagań

Bardziej szczegółowo

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

Opis realizacji dla czterech zespołów (4 przypadki użycia) Projektowanie oprogramowania Termin zajęć: czwartek, sala L2.6, C16 7.30-9.00, 9.15-10.45 Na podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1)

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

Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania

Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania Inżynieria oprogramowania przykładowe pytania egzaminacyjne str. 2 Przykładowe pytania 1. Wymień i omów krótko podstawowe kategorie

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

Jakość w procesie wytwarzania oprogramowania

Jakość w procesie wytwarzania oprogramowania Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu

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

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

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

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

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

Dwuwymiarowy sposób na podróbki > 34

Dwuwymiarowy sposób na podróbki > 34 TEMAT NUMERU I Bezpieczeństwo WIELE WYMIARÓW BEZPIECZEŃSTWA I zapobieganie zanieczyszczeniom krzyżowym I walka z fałszowaniem leków I walidacja rozwiązań chmurowych Maszyny rozwoju > 20 Dwuwymiarowy sposób

Bardziej szczegółowo

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura

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

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

Scrum. Zwinna metodyka prowadzenia projektów

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

Bardziej szczegółowo

Wprowadzenie do Behaviordriven

Wprowadzenie do Behaviordriven Wprowadzenie do Behaviordriven development Jakub Kosiński Email: ja@ghandal.net Czym jest BDD? praktyka, powstała na podstawie TDD, wykorzystywana w zwinnych metodykach stworzona przez Dana Northa w 2003

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

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

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

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

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

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

WPROWADZENIE DO UML-a

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

KARTA PRZEDMIOTU. Systemy czasu rzeczywistego: D1_9

KARTA PRZEDMIOTU. Systemy czasu rzeczywistego: D1_9 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom : Profil : Forma studiów: Obszar : Dziedzina:

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