Syllabus. REQB Certyfikowany specjalista inżynierii wymagań. Poziom podstawowy

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

Download "Syllabus. REQB Certyfikowany specjalista inżynierii wymagań. Poziom podstawowy"

Transkrypt

1 Syllabus REQB Certyfikowany specjalista inżynierii wymagań 1 Grudnia 2010 Prawa autorskie do tej edycji syllabusa dla wszystkich języków należą do Global Association for Software Quality, gasq

2 Podsumowanie zmian Wersja Data Komentarz PIerwsza wersja syllabusa; stworzenie podstawowej struktury syllabusa Rozszerzenie wersji Dalsze rozszerzenie i rewizja wersji Rewizja wersji Rewizja wersji Kompletnie zrewidowana wersja Wersja zrewidowana dla przeglądu Wersja Alpha Wersja Beta Wydanie Zaktualizowana wersja Zaktualizowana wersja PL Tłumaczenie wersji 1.2 na język polski Prawa autorskie do tego syllabusa dla wszystkich języków należą do Global Association for Software Quality, gasq 2

3 Nadrzędna idea Głównym tematem tego syllabusa jest ciągle rosnąca złożonośd oprogramowania i nasza zależnośd od niego. W rezultacie pojawia się wysoki poziom zależności od braku błędów w oprogramowaniu. Requirements Engineering Qualifications Board (REQB) postanowił zatem stworzyd jednolite międzynarodowe standardy w dziedzinie inżynierii wymagao. Standardy są jednak jak języki - tylko wtedy, gdy je zrozumiesz, możesz pracowad efektywnie. Aby stworzyd taki jednolity język w tak ważnej dziedzinie, jak inżynieria wymagao, międzynarodowi eksperci zebrali się w REQB i opracowali niniejszy syllabus. Tłumaczenie Oryginalna wersja syllabusa została przetłumaczona przez zespół gasq.pl oraz testerzy.pl w składzie: Michał Figarski, Dariusz Paczewski, Radosław Smilgin, Karolina Zmitrowicz. 3

4 1. Spis treści Wprowadzenie Podstawy Wymaganie Standardy i normy Procedury i procesy Modele procesowe Proces inżynierii wymagao Zarządzanie projektem i zarządzanie ryzykiem Zarządzanie projektem Zarządzanie ryzykiem Odpowiedzialności i role Podstawowe role Zadania w inżynierii wymagao Identyfikacja wymagao Klient Wizja i cele projektu Identyfikacja interesariuszy Techniki identyfikacji wymagao Wymagania funkcjonalne i niefunkcjonalne Opis wymagao Specyfikacja wymagao Specyfikacja Procedura Formalizacja Jakośd Wymagao Analiza wymagao Wymagania i rozwiązania

5 7.2. Metody i Techniki Analiza zorientowana obiektowo Estymacja Kosztów Priorytetyzacja Akceptacja wymagao Śledzenie wymagao Śledzenie wymagao w projekcie Zarządzanie zmianą Metryki Zapewnienie jakości Czynniki sukcesu Zapewnienie jakości poprzez testowalnośd Narzędzia Zalety narzędzi Kategorie narzędzi Literatura

6 Wprowadzenie Cel syllabusa Niniejszy syllabus definiuje poziom podstawowy (Foundation Level) programu szkolenia umożliwiającego zostanie certyfikowanym specjalistą inżynierii wymagao REQB (w skrócie CPRE - Certified Professional for Requirements Engineering). Syllabus ten został opracowany przez REQB we współpracy z Global Association for Software Quality. Syllabus ma służyd jako podstawa dla organizatorów szkoleo, którzy chcieliby pozyskad akredytację trenerską. Wszystkie obszary niniejszego syllabusa muszą byd odpowiednio włączone do materiałów szkoleniowych. Syllabus powinien jednak również służyd jako przygotowanie do certyfikacji. Wszystkie obszary wymienione tutaj są zatem istotne dla egzaminu, do którego można podchodzid albo po ukooczeniu akredytowanych kursów, albo podczas egzaminów otwartych. Certyfikacja Egzamin na certyfikowanego specjalistę inżynierii wymagao odbywa się na podstawie niniejszego syllabusa, dlatego wszystkie sekcje syllabusa mogą podlegad weryfikacji. Pytania egzaminacyjne muszą byd rozdzielone na poszczególne sekcje. Jedno pytanie może odnosid się do kilku sekcji syllabusa. Format egzaminu to test jednokrotnego wyboru. Do egzaminu można podejśd po uczestnictwie w akredytowanym kursie lub w bez wcześniejszego kursu podczas otwartych egzaminów. Szczegółowe informacje dotyczące terminów egzaminów można znaleźd na stronie internetowej gasq (www.gasq.org) lub na stronie internetowej REQB (www.reqb.org). Akredytacja Dostawcy kursu na certyfikowanego specjalistę inżynierii wymagao REQB muszą byd akredytowani przez Global Association for Software Quality. Eksperci GASQ dokonują przeglądu dokumentacji szkoleniowej pod kątem zgodności z syllabusem. Kurs akredytowany musi zostad uznany za zgodny z syllabusem. Na zakooczenie kursu prowadzonego na podstawie certyfikowanych materiałów może zostad przeprowadzony oficjalny egzamin na certyfikowanego specjalistę inżynierii wymagao (egzamin CPRE). Egzamin jest 6

7 przeprowadzany przez niezależny instytut certyfikacji (zgodnie z zasadami normy ISO 17024). Akredytowane ośrodki szkoleniowe są identyfikowane poprzez oficjalne logo akredytowanego dostawcy szkoleo REQB. Międzynarodowość Niniejszy syllabus został opracowany we współpracy grupy międzynarodowych ekspertów,. dlatego też jego zawartośd może byd postrzegana jako międzynarodowy standard. Tym samym syllabus umożliwia szkolenie i egzaminowanie na arenie międzynarodowej na jednakowym poziomie. Poziomy K Syllabus ten został podzielony na różne poziomy K. Pozwala to kandydatowi rozpoznad poziom wymaganej wiedzy każdego punktu. W obecnym syllabusie istnieją 3 K-poziomy: K1 zapamiętaj, rozpoznaj, przypomnij K2 zrozum, wyjaśnij, podaj powód, porównaj, sklasyfikuj, podsumuj K3 zastosuj w konkretnej sytuacji 7

8 1. Podstawy Cele nauczania Czym jest wymaganie? Jakie jest znaczenie i cel wymagao? Jak można sklasyfikowad wymagania? Jakie istnieją typy wymagao? Jakie problemy pojawiają się przy okazji wymagao? Jakie koncepcje są ważne w powiązaniu z wymaganiami? Jaka jest różnica pomiędzy Zarządzaniem Wymaganiami a Inżynierią Wymagao? Jakie istotne normy i standardy wiążą się z wymaganiami? Dlaczego zarządzanie wymaganiami jest ważne? 1.1. Wymaganie Definicja tego, co jest rozumiane pod pojęciem Wymaganie (K1) Słownik: IEEE : Wymaganie to warunek lub umiejętnośd potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu. Jakie jest znaczenie i cel wymagao? (K2) Podstawa dla oceny, planowania, przeprowadzania i monitorowania czynności projektowych Oczekiwania klienta Składnik umów, zamówieo, planów projektowych Ustanawianie granic systemu, zakresu dostawy, umownych usług serwisowych 8

9 Klasyfikacja wymagao (zgodnie z Ebert05) (K 2) Wymagania dzielimy na wymagania procesowe i wymagania produktowe. Wymagania procesowe: koszty, marketing, czas przetwarzania, sprzedaż, dystrybucja, organizacja, dokumentacja. Opisują potrzeby i ograniczenia procesów biznesowych. Wymagania produktowe składają się z funkcjonalnych i niefunkcjonalnych wymagao produktowych. Oba rodzaje mogą byd postrzegane z punktu widzenia użytkownika (zewnętrzne) lub klienta oraz z punktu widzenia dewelopera (wewnętrzne). Funkcjonalne wymagania produktowe z punktu widzenia użytkownika to: interfejs użytkownika (UI), aplikacje, usługi. Funkcjonalne wymagania produktowe z punktu widzenia klienta to: interfejs użytkownika (UI), aplikacje, usługi. Uwaga: Użytkownik i klient mogą byd różnymi osobami! Funkcjonalne wymagania produktowe z punktu widzenia dewelopera to: architektura, zasilanie, rozkład obciążenia. Wymagania funkcjonalne opisują funkcje systemu. Niefunkcjonalne wymagania produktowe z punktu widzenia użytkownika to: niezawodnośd, wydajnośd, użytecznośd. Niefunkcjonalne wymagania produktowe z punktu widzenia klienta to: niezawodnośd, wydajnośd, użytecznośd. Niefunkcjonalne wymagania produktowe z punktu widzenia dewelopera to: testowalnośd, utrzymanie, narzędzia. Wymagania niefunkcjonalne opisują atrybuty jakościowe systemu. 9

10 Typy wymagao: wymagania klienta, wymagania systemowe lub też specyficzne dla danego rozwiązania, wymagania produktowe/komponentowe. Problemy związane z wymaganiami (K2): Niejasne cele Problemy komunikacyjne Bariery językowe Bariery wiedzy Ogólnikowe sformułowania Zbyt formalne określenia Dwuznaczne, nadmiernie specyfikowane, niejasne, niemożliwe, sprzeczne sformułowania Niestabilnośd wymagao Zła jakośd wymagao Zbytnie ozłocenie Niewystarczające zaangażowanie użytkowników Pominięte klasy użytkownika Nieprecyzyjne planowanie Minimalna specyfikacja Kryteria jakościowe dla wymagao (według Wiegers05): (K2) 1. Każde wymaganie musi byd kompletne, poprawne, wykonalne, niezbędne, spriorytetyzowane, jednoznaczne, weryfikowalne 2. Specyfikacja wymagao musi byd kompletna, spójna, modyfikowalna i umożliwiająca śledzenie zmian Dla firm szkoleniowych: wyjaśnid poszczególne kryteria jakościowe. Rozwiązanie (K1) Rozwiązanie jest implementacją wymagao. Zobowiązanie (K1) Zobowiązanie jest poziomem zobligowania się do wykonania czegoś. 10

11 Definiowanie zobowiązania poprzez słowa kluczowe. Dla firm szkoleniowych: wyjaśnid słowa kluczowe. Obserwacja aspektów prawnych, szczególnie na okolicznośd usterek. Usterka (K1) Odstępstwo aktualnego stanu od oczekiwanego stanu. Priorytety wymagao (K1) Ocena ważności/pilności. Krytycznośd wymagao (K1) Ocena ryzyka powiązanego z wymaganiem poprzez ocenę szkód w przypadku niespełnienia wymagania. Walidacja (K1) Proces potwierdzania, że specyfikacja danej fazy lub cały system spełnia wymagania klienta. Weryfikacja (K1) Porównanie pośredniego produktu z jego specyfikacją. Weryfikacja jest więc ustaleniem, czy oprogramowanie zostało przygotowane poprawnie i zgodnie ze specyfikacją przygotowaną w poprzednich fazach. Rozgraniczenie pomiędzy zarządzaniem a inżynierią wymagao. (K2) Zarządzanie Wymaganiami obejmuje procesy służące identyfikacji i zarządzaniu wymaganiami. Inżynieria wymagao zawiera podstawowe umiejętności inżynierskie. Dla firm szkoleniowych: rozwinąd opisy poszczególnych obszarów. 11

12 1.2. Standardy i normy ISO 9000: Wymagania w stosunku do systemu zarządzania jakością. ISO 9126: Zdefiniowana podstawowa koncepcja Systemów Zarządzania Jakością (ang. Quality Management System, QMS) Koncepcja niezależna od domeny lub gałęzi przemysłu Definiuje model jakości w sześciu kategoriach: Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd. IEEE 610: Standardowy Słownik dla Terminologii Inżynierii Oprogramowania, IEEE 830: Rekomendowane Praktyki dla Specyfikacji Wymagao Oprogramowania. IEEE 1233: Wytyczne do Opracowywania Specyfikacji Wymagao Oprogramowania. IEEE 1362: Wytyczne dla Technologii Informacyjnych Definicja Systemu. Normy procesowe: ISO 12207: Standard dla Procesu Cyklu Życia Oprogramowania. ISO 15288: Proces Cyklu Życia Oprogramowania. 12

13 ISO 15504: Ulepszanie i określanie możliwości procesu oprogramowania (ang. Software Process Improvement and Capability Determination (SPICE)) CMMI Zintegrowany Model Dojrzałości Zdolności (ang. Capability Maturity Model Integrated) Aby zdad egzamin nie trzeba znad zawartości każdej z tych norm. Ważne jest jednak (K1), by wiedzied, które normy są istotne dla Inżynierii Wymagao. Inżynieria wymagao ma kluczowe znaczenie, jednak nadal jest zaniedbywana. Dla firm szkoleniowych: podkreślid wagę Inżynierii wymagao i powodów, dla których jest często pomijana (K2). Zaniedbywanie z powodu dużej presji czasu Zaniedbanie ze względu na zorientowanie na szybkie rezultaty Zaniedbanie ze względu na ograniczanie kosztów Zaniedbanie ze względu na niewłaściwą interpretację (wiele rzeczy jest postrzeganych tak, jak podano) Możliwe konsekwencje zaniedbao w Inżynierii Wymagao (K2): Wymagania stają się nieprecyzyjne Wymagania są niejednoznaczne Wymagania są sprzeczne Wymagania, które się zmieniają Wymagania niespełniające kryteriów Wymagania, które mogą byd interpretowane w różny sposób Brakujące wymagania 13

14 2. Procedury i procesy Cele nauczania Jakie istnieją modele procesowe? Czym różnią się modele? Czym charakteryzuje się proces inżynierii wymagao? Jakie istnieją fazy procesu inżynierii wymagao? 2.1. Modele procesowe Modele proceduralne (K2) Niezależny od metody opis procesu wytwarzania oprogramowania. Uwzględnione są : role, aktywności, fazy i dokumenty. Cykl życia produktu (ang. Product life cycle (PLC)) (K2) Podstawowe fazy: planowanie, rozwój, utrzymanie, koniec życia. Faza planowania zawiera: wizję, strategię, biznesplan, analizę kosztów/korzyści. Faza rozwoju zawiera: specyfikację, projekt i implementację. Definiuje różne fazy wytwarzania produktu. Ogólny Model V (K 2) Fazy rozwoju oprogramowania: Zdefiniowanie i określenie wymagao (specyfikacja wydajnościowa) Projektowanie systemu od strony funkcjonalnej, analiza systemu (specyfikacja funkcjonalna) Projektowanie techniczne, projekt architektury (projekt oprogramowania) Specyfikacja komponentów 14

15 Implementacja Dla firm szkoleniowych: wymagane graficzne przedstawienie Ogólnego Modelu V, dogłębny opis Modelu V. Rational Unified Process (RUP ) (K2) Model proceduralny od IBM Rational Iteracyjny proces rozwojowy: 4 fazy (powstanie, opracowanie (elaboracja), budowa, przekazanie) 9 dyscyplin (między innym - wymagania) Dla firm szkoleniowych: graficzne przedstawienie RUP, pogłębione e studium dyscypliny wymagao. Programowanie ekstremalne (K2) Model proceduralny stworzony przez Kenta Becka Zarządzanie wymaganiami jako główny komponent Absolutnie bez inwestygacji (dochodzenia) wymagao Dla firm szkoleniowych: wyjaśnid co najmniej trzy modele zwinne włączając w to Scrum i Crystal. Stopieo modelu dojrzałości (K2) Identyfikacja i ulepszanie dojrzałości procesu (ocena procesu i ulepszanie procesu) Definicja stopnia dojrzałości i powiązanej z nim specyfikacji procesowej Dla firm szkoleniowych: pogłębid na przykładzie ISO 15504/SPICE; wraz z opisem typowych wymagao dla Inżynierii Wymagao. 15

16 2.2. Proces inżynierii wymagao Proces nie będący procesem głównym, który dotyczy wszystkich faz rozwoju systemów: Identyfikacja wymagao Analiza wymagao Specyfikacja wymagao Zmiany w wymaganiach Weryfikacja Zapewnienie jakości Opis czynników wpływających negatywnie na procesy. Opis różnych punktów widzenia (klienta, dostawcy). Metoda procesu inżynierii wymagao z klientem w centrum. 16

17 3. Zarządzanie projektem i zarządzanie ryzykiem Cele nauczania Dlaczego inżynieria wymagao jest ważna w projekcie? Jakie błędy mogą się pojawid w inżynierii wymagao? Jakie ryzyka są powiązane z wymaganiami? 3.1. Zarządzanie projektem Wyjaśnienie niezbędności Inżynierii Wymagao w projektach informatycznych (K2) Inżynieria wymagao powinna wnieśd wkład do następujących obszarów: (K 1) Koncepcji projektu Negocjacji kontraktu Definicji projektu Wykonania projektu Dla firm szkoleniowych: bardziej szczegółowy opis inżynierii wymagao w tych obszarach. Jakie błędy mogą wystąpid w inżynierii wymagao? (K2) Niejasne wymagania Zmieniające się wymagania Niestabilna podstawa produktu i projektu dla podwykonawców Niejasne odpowiedzialności Rozbieżnośd pomiędzy oczekiwaniami klienta i treścią projektu Nieefektywne zarządzanie kontaktami z klientem Definicja projektu z nieosiągalnymi kamieniami milowymi Nieprecyzyjne oszacowanie kosztów Nieprecyzyjne oszacowanie wpływu 17

18 3.2. Zarządzanie ryzykiem Wyjaśnij niezbędnośd zarządzania ryzykiem (K3) Efektywne zarządzanie ryzykiem jako klucz do obniżenia ryzyka w projekcie. Dla firm szkoleniowych: dostarcz szczegółowy opis rozwoju środków zaradczych i technik zarządzania ryzykiem, (takich jak, na przykład, analiza przyczyn i skutków awarii (ang. Failure Mode and Effect Analysis (FMEA)). 18

19 4. Odpowiedzialności i role Cele nauczania Jakie są podstawowe role w inżynierii wymagao? Kim jest interesariusz? Jakie zadania stoją za inżynierią wymagao? Jakie jest zadanie specjalisty inżynierii wymagao? Co charakteryzuje specjalistę inżynierii wymagao? 4.1. Podstawowe role Podstawowe role: (K2) Klient Kontraktor (= Dostawca) Klient określa swoje potrzeby. Dostawca dostarcza rozwiązanie. Interesariusz Interesariusz jest osobą (lub rolą), która jest zainteresowana projektem. Interesariusz może byd zarówno osobą fizyczną, osobą prawną, jak i postacią abstrakcyjną. Interesariusze często napotykają na konflikt interesów między sobą. Dla firm szkoleniowych: opisz typowych interesariuszy (np. dyrektor zarządzający, kierownik projektu, klient). 19

20 Ważne: Identyfikacja wszystkich interesariuszy dla poprawnego rozważenia wszystkich perspektyw Zadania w inżynierii wymagao Zadania: (K2) Analiza procesów biznesowych Identyfikacja i analiza wymagao Zapewnienie jakości wymagao i specyfikacji Stworzenie specyfikacji wymagao Analiza ryzyka Specjalista inżynierii wymagao identyfikuje życzenia i cele. Wiedza i charakterystyka specjalisty inżynierii wymagao: (K1) Umiejętnośd moderowania Pewnośd siebie Umiejętnośd przekonywania Umiejętności językowe Umiejętnośd komunikowania się Precyzja Analityczny umysł Zdolnośd do działania w sposób ustrukturyzowany Kompetencje metodologiczne Odpornośd na stres 20

21 5. Identyfikacja wymagao Cele nauczania Co powinien zawierad kontrakt? Co powinno byd uwzględniane przy ocenie wymagao? Co charakteryzuje typową wizję projektową? Jak można zidentyfikowad interesariuszy? Jaki jest cel identyfikacji wymagao? Jakie techniki pomagają identyfikowad wymagania? Czym charakteryzują się wymagania funkcjonalne i niefunkcjonalne? Czym różnią się wymagania funkcjonale i niefunkcjonalne? Co powinno zostad zawarte w dokumentacji wymagao? Czym charakteryzuje się dobre wymaganie? Jak wygląda standardowa zawartośd dokumentu wymagao? Jak zbudowane jest wymaganie? 5.1. Klient Klient musi byd zawsze zaangażowany. Celem zaangażowania jest zrozumienie klienta i jednoczesne stworzenie atmosfery do wzajemnego zrozumienia. Dostawca powinien zawsze stawiad się w sytuacji klienta. Kontrakt: (K2) W umowie powinno byd formalnie określone i opisane to, czego chce klient. Należy zapewnid, że interes klienta jest na pierwszym miejscu. 21

22 Ważne jest, by zdefiniowad realistyczne terminy i ceny, oraz dokonad realnego planowania projektu. Kiedy wymagania są oceniane, należy wziąd pod uwagę różne punkty widzenia Wizja i cele projektu Na początku odbywa się opracowanie wizji projektu. Jest to pierwsza faza inżynierii wymagao. Kluczowe jest posiadanie jasnej definicji wizji projektu. Dla firm szkoleniowych: zaprezentowad typowe wizje projektu. Ważne pytania dotyczące wizji projektu: (K2) Co projekt zmieni? Do czego projekt jest potrzebny? Co się zdarzy kiedy projekt zostanie przerwany? Kto zyska na projekcie? Jakie koszty jesteśmy w stanie ponieśd? Jakie ryzyko jesteśmy gotowi podjąd? Dla firm szkoleniowych: zaprezentowad typowe elementy wpływające na wizje projektu (klienci, strategia, etc.) Dla każdego projektu, wizja musi zostad zdefiniowana na nowo 5.3. Identyfikacja interesariuszy Wszyscy interesariusze po stronie klienta i dostawcy muszą zostad zidentyfikowani. Interesariusze powinni byd podzieleni na grupy interesów. Dla firm szkoleniowych: wyjaśnid identyfikację i ocenę interesariuszy. 22

23 5.4. Techniki identyfikacji wymagao Cel identyfikacji wymagao (K2) Techniki (K1) Identyfikacja wszystkich wymaganych funkcji, charakterystyk, ograniczeo i oczekiwao Zorientowanie wymagao w kierunku wizji projektu Funkcje muszą byd jasno opisane Funkcje, których klient nie chce powinny byd wykluczone Kwestionariusze Wywiady Samodzielna rejestracja Reprezentant klienta po stronie dostawcy Identyfikacja na podstawie istniejących dokumentów Ponowne użycie specyfikacji z podobnych projektów Burza mózgów Obserwacja w terenie Terminowanie (praktykowanie) (ang. apprenticing) Warsztaty po każdym wymienionym procesie Dla firm szkoleniowych: zaprezentowad techniki, włączając opis korzyści i wad. Dla firm szkoleniowych: wyjaśnid opis metod odpytywania dla wywiadów Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne (K2) Opis funkcji systemu Wyzwalacze (uruchomienie) procesu Wymagania niefunkcjonalne (K2) Opisują atrybuty funkcji lub ich charakterystyki jakościowe Trudne do opisania, dlatego często niejasno sformułowane 23

24 Często trudne do śledzenia i testowania Precyzyjny i jasny opis jest konieczny dla walidacji Dla firm szkoleniowych: dostarczyd przykłady wymagao funkcjonalnych i niefunkcjonalnych. Charakterystyki jakościowe zgodnie z ISO 9126: (K2) Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd Dla firm szkoleniowych uszczegółowid poszczególne charakterystyki jakościowe. Dla firm szkoleniowych: opisad ograniczenia (np. specyfikacje techniczne) Opis wymagao Zawartośd tekstu wymagania: Kto? Co? Jak? Kiedy? Z kim? Na co wpływa? Ważne wskazówki do tworzenia dokumentacji wymagao: (K2) Wymagania muszą byd jednoznaczne, precyzyjne i zrozumiałe Należy unikad zbędnych informacji Szablony jako pomoc do ograniczenia opisów Standardowa zawartośd dokumentu wymagao: (K1) Wprowadzenie Klauzula tajności Regulacje Standardy Interesariusze Przeznaczenie produktu Opis systemu Wymagania funkcjonalne Wymagania niefunkcjonalne 24

25 Założenia Zależności Ryzyka Wymagania bezpieczeostwa Atrybuty jakości oprogramowania Akceptacja Konstruowanie wymagao (K2) 1. Określenie procesu 2. Klasyfikacja czynności systemu 3. Określenie zobowiązao prawnych 4. Poprawienie procesu 5. Ograniczenia logiczne i czasowe Dla firm szkoleniowych: opis poszczególnych kroków w konstruowaniu wymagao. 25

26 6. Specyfikacja wymagao Cele nauczania Czym jest specyfikacja wymagao? Co charakteryzuje specyfikację wymagao? Czym jest specyfikacja rozwiązania? Co charakteryzuję specyfikację rozwiązania? Jakie standardy są ważne dla specyfikacji wymagao i specyfikacji rozwiązao? Jak wygląda typowa procedura w odniesieniu do specyfikowania wymagao? Jakie istnieją poziomy formalizacji dla specyfikacji wymagao? Jakie mogą byd konsekwencje błędów w wymaganiach? Jak unikad błędów w wymaganiach? 6.1. Specyfikacja W specyfikacji wymagania są opisane w ustrukturyzowany sposób i oddzielnie modelowane. Specyfikacja służy do śledzenia i zarządzania wymaganiami. Specyfikacja wymagao (K2) Nazywana również specyfikacją wydajności. Jej stworzenie powinno byd zadaniem klienta. Specyfikacja rozwiązania (K2) Zwana również specyfikacją funkcjonalną. 26

27 Podstawa do dalszego rozwoju systemu. Ważne standardy: (K1) IEEE 1362 (specyfikacje wydajności systemu), IEEE 830 (specyfikacje wymagao systemu), IEEE 1233 (specyfikacje funkcjonalne systemu) Dla firm szkoleniowych: dostarczyd bardziej szczegółowy opis specyfikacji wydajności oraz specyfikacji funkcjonalnej Procedura Specyfikacja jako czynnośd służąca formalizacji wyników analizy wymagao (K2) Dla firm szkoleniowych: opisad kroki specyfikacji problemów i rozwiązao (określanie przestrzeni rozwiązania, opisywanie kontaktów klienta, etc.) Faza identyfikacji zostaje zakooczona, kiedy wszystkie niezbędne umowy zostały podpisane Formalizacja Różne stopnie formalizacji Nieformalna Pół-formalna Formalna Dla firm szkoleniowych: dostarczyd opis i rozróżnienie pomiędzy stopniami formalizacji (K2) 27

28 6.4. Jakość Wymagao Błędy w wymaganiach jako przyczyna wysokich kosztów (K2) Im później błąd zostanie znaleziony, tym większe są koszty jego naprawy. Dlatego używamy ręcznej weryfikacji (czy właściwie produkujemy produkt?) i walidacji (czy produkujemy właściwy produkt?). Dla firm szkoleniowych: opisad miary ulepszania i zapewniania jakości. 28

29 7. Analiza wymagao Cele nauczania Jaki jest cel analizy wymagao? Jakie procedury stosowane są podczas analizy wymagao? Jakie istnieją modele analizy wymagao? Co charakteryzuje UML? Co charakteryzuje SySML? Dlaczego estymujemy koszty? Jakie są ważne czynniki przy estymacji kosztów? Jak wygląd procedura przyznawania priorytetów? Co musi byd brane pod uwagę przy podejmowaniu decyzji dotyczących wymagao? 7.1. Wymagania i rozwiązania Cel analizy wymagao: rozwiązanie dla implementacji wymagao (K2) Procedura: 1. Analiza potrzeb 2. Opis rozwiązania 3. Estymacja kosztów i ustalenie priorytetów 29

30 7.2. Metody i Techniki Różne aspekty systemu są reprezentowane przez różne punkty widzenia. Modele są opracowywane poprzez odpowiednie metody analizy. Zróżnicowanie pomiędzy różnymi typami modeli (K2) Modele wymagao Modele rozwiązania Dla firm szkoleniowych: dostarczyd szczegółowy opis tych dwóch typów i ich widoków. Różne modele (K1) Model kontekstowy Dekompozycja funkcjonalna Model przepływu danych Model przejśd stanów Sied Petriego Model związków encji Dla firm szkoleniowych: szczegółowy opis wymienionych modeli Analiza zorientowana obiektowo UML (Unified Modeling Language) UML dostarcza diagramy dla różnych punktów widzenia systemu. Diagramy przypadków użycia, diagramy klas, diagramy aktywności, diagramy stanów, diagramy obiektów, diagramy komponentów, diagramy pakietów, itd. Dla firm szkoleniowych: dostarczyd przykłady diagramów (co najmniej diagramów przypadków użycia, klas, aktywności i stanów). SysML (Systems Modeling Language) jako rozwinięcie UML. 30

31 7.4. Estymacja Kosztów Estymacja kosztów łączy inżynierię wymagao z zarządzaniem projektem. Typy estymat (K2) Koszty Czas Wymagania Jakośd Estymaty kosztów pomagają rozpoznawad koszty zmian. Dla firm szkoleniowych: opisad czynniki determinujące koszty wytwarzania. Procedury estymacji (K 1) Wnioski przez analogię Procedura algorytmiczna Procedura punktów funkcyjnych Konstruktywny model kosztowy Metoda Delphi (delfijska) Dla firm szkoleniowych: wyjaśnienie procedury estymacji. Procedury estymacji zawsze bazują na danych historycznych i ograniczeniach środowiska Priorytetyzacja Procedura 1. Grupowanie wymagao 2. Analiza wymagao 3. Budowanie planu projektu 4. Testowanie przyrostowe 31

32 7.6. Akceptacja wymagao Umowy (K2) Umowy formalne jako podstawa projektu Lista wymagao musi byd wiążąca Konieczny jest ciągły przegląd wymagao Dla firm szkoleniowych: opis korzyści wynikających z wiążących alokacji. 32

33 8. Śledzenie wymagao Cele nauczania Czym jest możliwośd śledzenia? Dlaczego wymagania się zmieniają? Jaki jest cel śledzenia? Jakie są typy śledzenia? Czym charakteryzuje się zarządzanie zmianą? Jaki jest skład komitetu kontroli zmian? Jakie istnieją metryki? Co umożliwiają metryki? 8.1. Śledzenie wymagao w projekcie Możliwośd śledzenia (K2) Wymagania nie są stabilne i ciągle się rozwijają Powody ciągłych zmian Nowe spojrzenie Nowe potrzeby klienta Kontynuowanie prac Nowe połączenia w ramach projektu Możliwośd śledzenia jako rozwiązanie: Umożliwia sprawdzenie, czy wszystkie istotne etapy procesu rozwoju zostały przeprowadzone. 33

34 Cele: analiza wpływu, analiza pokrycia, analiza użycia potencjału, dowód implementacji, użycie wymagao, itd. W celu zapewnienia dobrej możliwości śledzenia, ważne jest, by precyzyjnie nazywad wymagania. Typy możliwości śledzenia: Śledzenie pionowe i poziome. Dla firm szkoleniowych: opisad, czym jest śledzenie pionowe i poziome Zarządzanie zmianą Zmiany w wymaganiach (zarządzanie zmianą) (K2) Zmiany są sprawdzane, a decyzja o dalszym postępowaniu musi byd podjęta przez komitet kontroli zmian. Komitet podejmuje decyzję odnośnie żądao zmian. Komitet kontroli zmian składa się z (K1) Kierownika projektu Członków zespołu programistów Członków zespołu zapewnienia jakości Menadżera biznesowego (jeśli konieczne) Klienta (jeśli konieczne) itd. Dla firm szkoleniowych: przedstaw zadania komitetu kontroli zmian. Dla zmiany wymagao konieczny jest ustrukturyzowany proces. Ważna jest analiza znaczenia każdej zmiany. Pośpieszne rozwiązania są problematyczne. Rozległe zmiany wymagao mogą byd na tyle poważne, że wymuszą zmiany kontraktów. Dla firm szkoleniowych: opisad cyklu życia wymagania. 34

35 Dla firm szkoleniowych: wyjaśnid wpływ zmian w wymaganiach. Dla firm szkoleniowych: rozróżnid pomiędzy zarządzaniem błędami a zarządzaniem zmianą Metryki Metryki umożliwiają wydanie mierzalnego oświadczenia odnośnie statusu i jakości projektu. Liczby muszą zawsze byd porównane z danymi referencyjnymi. Metryki dla wymagao: (K1) Koszt projektu Śledzenie projektu Stabilnośd projektu Ulepszanie procesu Jakośd specyfikacji Ilośd błędów Typy błędów Pomiar jakości wymagao: (K2) Czy wymagania są poprawne? Czy wymagania są czytelne? Czym wyższa częstotliwośd zmian, tym wyższe ryzyko projektowe. 35

36 9. Zapewnienie jakości Cele nauczania Jakie czynniki wpływają na inżynierię wymagao? Jak można usprawnid zapewnienie jakości? Czym jest kryterium akceptacji? Jakie znamy metody zapewnienia jakości? 9.1. Czynniki sukcesu Czynniki wpływające na sukces inżynierii wymagao: (K2) Produkt, jaki jest wytwarzany Środowisko, w jakim produkt zostaje wytwarzany Przemysł Presja czasu Presja kosztów Czynniki społeczne Takie czynniki muszą byd wzięte pod uwagę w procesie zapewnienia jakości Wyżej wymienione czynniki muszą byd wzięte pod uwagę, jeśli chodzi o zapewnienie jakości Zapewnienie jakości poprzez testowalność Inżynieria wymagao jest obecna w całym cyklu życia produktu. Inżynieria wymagao jest ściśle powiązana z testowaniem. Dobry przypadek testowy wymaga dobrych wymagao, które mogą byd przetestowane (zaangażowanie testerów w specyfikowaniu wymagao jest kluczowe) (K2) 36

37 Kryteria akceptacji Metody: Każde wymaganie ma przynajmniej jedno kryterium akceptacji Stanowi podstawę do testów akceptacyjnych Pokrycie funkcjonalne Podzbiory równoważności Dla firm szkoleniowych: opisad metody. 37

38 10. Narzędzia Cele nauczania Jak narzędzia wspierają inżynierię wymagao? Jakie czynności związane z inżynieria wymagao mogą byd przeniesione do narzędzia? Jakie istnieją wymagania na narzędzia do inżynierii wymagao? Co musi byd brane pod uwagę w odniesieniu do narzędzi? Zalety narzędzi Narzędzia do przechowywania i administracji wymagao wspomagają inżynierię wymagao. Mogą one automatyzowad powtarzalne czynności lub zapewnid łatwy wgląd w wymagania. W ten sposób można utrzymywad trudne, statyczne dokumenty w spójnym i aktualnym stanie. Wybór narzędzia musi nastąpid przed wytworzeniem produktu. W innym wypadku może to spowodowad poważne problemy (K2) Dla firm szkoleniowych: dostarczyd opis wymagao stawianych narzędziom w zakresie inżynierii wymagao. Dla firm szkoleniowych: dostarczyd opis czynności inżynierii wymagao, które mogą byd wspierane przez wykorzystanie narzędzi Kategorie narzędzi Narzędzia przetwarzające tekst, arkusze kalkulacyjne o MS Excel, MS Word itd. Narzędzia do modelowania Narzędzia do zarządzania wymaganiami Narzędzia do zarządzania defektami Narzędzia Open Source 38

39 Koszty narzędzi znacznie się różnią. Wybór narzędzia musi byd dokonany bardzo ostrożnie. Pośpieszne decyzje mogą powodowad wysokie koszty. (K2) 39

40 11. Literatura Beck, Kent: Extreme Programming. Munich 2003 Beck, Kent: Extreme Programming Explained: Embrace Change. Boston 2000 Beck, Kent: Test Driven Development. By Example. Amsterdam 2002 Beck, Kent: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman 1999 Boehm, Barry: Software Engineering Economics. Englewoods Cliffs, NJ 1981 Bundschuh, Manfred; Fabry, Axel: Aufwandschätzung von IT-Projekten. Bonn 2004 Cockburn, Alistair: Agile Software Development. Addison Wesley 2002 Cockburn, Alistair: Writing Effective Use Cases. Amsterdam 2000 DeMarco, Tom et al.: Adrenalin-Junkies und Formular-Zombies Typisches Verhalten in Projekten. Munich 2007 DeMarco, Tom: Controlling Software Projects: Management, Measurement and Estimates. Prentice Hall 1986 DeMarco, Tom: The Deadline: A Novel About Project Management. New York 1997 Ebert, Christof: Systematisches Requirements Management. Anforderungen ermitteln, spezifizieren, analysieren und verfolgen. Heidelberg 2005 Evans, Eric J: Domain-Driven Design: Tackling Complexity in the Heart of Software. Amsterdam 2003 Graham, Dorothy et al: Foundations of Software Testing. London 2007 Gilb, Tom; Graham, Dorothy: Software Inspection. Reading, MA 1993 Hull, Elizabeth et. All: Requirements Engineering. Oxford 2005 IEEE Standard IEEE Standard Glossary of Software Engineering Terminology IEEE Standard IEEE Guide for Developing System Requirements Specifications 40

41 IEEE Standard IEEE Standard for Siftware Test Documentation IEEE Standard IEEE Recommended Practice for Software Requirements Specifications IEEE Standard IEEE Guide for Information Technology-System Definition Concept of Operations (ConOps) Document IEEE Standard : IEEE Standard for Application and Management of Systems Engineering Process ISO 9000 ISO 9126 ISO ISO ISO Jacobsen, Ivar et al.: The Unified Software Development Process. Reading 1999 Lauesen, Soren: Software Requirements: Styles and Techniques. London 2002 Mangold, Pascal: IT-Projektmanagement kompakt. Munich 2004 McConnell, Steve: Aufwandschätzung für Softwareprojekte. Unterschleißheim 2006 Paulk, Mark, et al: The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA 1995 Pfleeger, Shari Lawrence: Software Engineering: Theory and Practice, 2nd edition. Englewood Cliffs, NJ 2001 Pohl, Klaus: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg 2007 Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). PMI 2004 Robertson. Suzanne; Robertson, James: Mastering the Requirements Process, Harlow

42 Rupp, Chris: Requirements-Engineering und Management. Professionelle, Iterative Anforderungsanalyse in der Praxis. Munich 2007 Sommerville, Ian: Requirements Engineering. West Sussex 2004 Sommerville, Ian: Software Engineering 8. Harlow 2007 Sommerville, Ian; Sawyer, Pete: Requirements Engineering: A Good Practice Guide. Chichester 1997 Sommerville, Ian; Kotonya, Gerald: Requirements Engineering: Processes and Techniques. Chichester 1998 Spillner, Andreas et all: Software Testing Foundations. Santa Barbara, CA 2007 Thayer, Richard H.; Dorfman, Merlin: Software Requirements Engineering, 2nd edition. Los Alamitos, CA 1997 V-Modell XT: Wiegers, Karl E.: Software Requirements. Redmond 2005 Wiegers, Karl E.: More About Software Requirements: Thorny Issues and Practical Advice. Redmond, Washington

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

Syllabus. REQB Certyfikowany Profesjonalista Inżynierii Wymagao. Poziom Podstawowy

Syllabus. REQB Certyfikowany Profesjonalista Inżynierii Wymagao. Poziom Podstawowy Syllabus REQB Certyfikowany Profesjonalista Inżynierii Wymagao Wersja 1.3 2011 Prawa autorskie do tej edycji syllabusa dla wszystkich języków należą do Global Association for Software Quality, gasq Historia

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania

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

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

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

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

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

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

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

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

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

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

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

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

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

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

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

Testy poziom po poziomie

Testy poziom po poziomie poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.

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

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji dr inż. Bolesław Szomański Wydział Zarządzania Politechnika Warszawska b.szomański@wz.pw.edu.pl Plan Prezentacji

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

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. 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

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

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

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

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

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

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

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

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy Wykład 5 (1) Jakość w projekcie informatycznym - normy ISO: Ogólne dot. jakości: ISO 8402 - terminologia ISO 9000 - wytyczne dotyczące wyboru modelu ISO 9001/3 - modele systemu jakości Dot. oprogramowania:

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

Cykl życia testów i integracja według modelu TMMi

Cykl życia testów i integracja według modelu TMMi Magazine Cykl życia testów i integracja według modelu TMMi Autor: Piotr Piotrowski O autorze: Inżynier Testów w Tieto Polska, gdzie zajmuje się: tworzeniem przypadków testowych, prostych planów testów,

Bardziej szczegółowo

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE ŚcieŜki Certyfikacji Testera Karol Mioduszewski - CORRSE Kierunki rozwoju W dół, w górę czy w bok? Rozwój w dół Specjalizacja Zagłębianie się w wybrany wycinek wiedzy, np. testy wydajnościowe lub konkretne

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

Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny?

Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny? Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny? 14:45 15:15 Bogdan Bereza @ victo.eu @ I Konferencja SASO - Inżynieria Jakości Oprogramowania Poznań, 25 września 2014 1(20) Automated

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

Matryca efektów kształcenia dla programu studiów podyplomowych ZARZĄDZANIE I SYSTEMY ZARZĄDZANIA JAKOŚCIĄ

Matryca efektów kształcenia dla programu studiów podyplomowych ZARZĄDZANIE I SYSTEMY ZARZĄDZANIA JAKOŚCIĄ Podstawy firmą Marketingowe aspekty jakością Podstawy prawa gospodarczego w SZJ Zarządzanie Jakością (TQM) Zarządzanie logistyczne w SZJ Wymagania norm ISO serii 9000 Dokumentacja w SZJ Metody i Techniki

Bardziej szczegółowo

Inżynierski Projekt Zespołowy

Inżynierski Projekt Zespołowy Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,

Bardziej szczegółowo

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.

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

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

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

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt 0-618 Lublin tel. (+8 81) 58 7 1/ fax (+8 81) 58 5 80 Przedmiot: Rok: INF I Inżynieria Semestr: V Rodzaj zajęć i liczba godzin: Studia stacjonarne Studia niestacjonarne Wykład 0 1 Ćwiczenia Laboratorium

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

Metodyka dla projektu SYRIUSZ

Metodyka dla projektu SYRIUSZ Metodyka dla projektu SYRIUSZ Wprowadzenie Robert Ganowski Warszawa, 29 lipca 2003 r. Czym się zajmujemy? * Program Low Produkt Change programowy Essential (Uogólnienie, testowanie, Money dokumentacja,

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

Katalog szkoleń certyfikowanych Testowanie Oprogramowania

Katalog szkoleń certyfikowanych Testowanie Oprogramowania Katalog szkoleń certyfikowanych Testowanie Oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

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

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

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

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

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. Na szkolenie zapraszamy: testerów kierowników działów testowych analityków systemowych

Bardziej szczegółowo

Egzamin ITIL Foundation

Egzamin ITIL Foundation Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.

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

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

Katalog szkoleń certyfikowanych Testowanie oprogramowania

Katalog szkoleń certyfikowanych Testowanie oprogramowania Katalog szkoleń certyfikowanych Testowanie oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka Zmiany w standardzie ISO 9001 dr inż. Ilona Błaszczyk Politechnika Łódzka 1 W prezentacji przedstawiono zmiany w normie ISO 9001 w oparciu o projekt komitetu. 2 3 4 5 6 Zmiany w zakresie terminów używanych

Bardziej szczegółowo

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu Zarządzanie ryzykiem w projektach informatycznych Marcin Krysiński marcin@krysinski.eu O czym będziemy mówić? Zarządzanie ryzykiem Co to jest ryzyko Planowanie zarządzania ryzykiem Identyfikacja czynników

Bardziej szczegółowo

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na

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ęść 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

Marek Krętowski e-mail: mkret@ii.pb.bialystok.pl http://aragorn.pb.bialystok.pl/~mkret. Wydział Informatyki PB. Wersja 1.1 IO2 (wyk.

Marek Krętowski e-mail: mkret@ii.pb.bialystok.pl http://aragorn.pb.bialystok.pl/~mkret. Wydział Informatyki PB. Wersja 1.1 IO2 (wyk. Wydział Informatyki PB Wprowadzenie Inżynieria oprogramowania II Wykład: Ocena i poprawa wytwórczego Marek Krętowski e-mail: mkret@ii.pb.bialystok.pl http://aragorn.pb.bialystok.pl/~mkret Każda organizacja

Bardziej szczegółowo

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska , e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 [ISO 9000] Jakość jest określana jako ogół cech i właściwości wyrobu lub usługi wymaganych do zaspokojenia stwierdzonych lub przewidywanych

Bardziej szczegółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin

Bardziej szczegółowo

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 1 Zbigniew Misiak (BOC IT Consulting) Podyplomowe Studia Menedżerskie Zarządzanie projektami informatycznymi Czym się będziemy zajmować?

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

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

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Jak teoria pomaga w codziennej praktyce zapewniania i kontroli jakości Piotr Ślęzak Stowarzyszenie Jakości Systemów Informatycznych

Bardziej szczegółowo

OGŁOSZENIE DODATKOWYCH INFORMACJI, INFORMACJE O NIEKOMPLETNEJ PROCEDURZE LUB SPROSTOWANIE

OGŁOSZENIE DODATKOWYCH INFORMACJI, INFORMACJE O NIEKOMPLETNEJ PROCEDURZE LUB SPROSTOWANIE 1/ 11 ENOTICES_CPIMSWiA 25/06/2010- ID:2010-081521 Formularz standardowy 14 PL Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, L-2985 Luksemburg Faks (352) 29 29-42670 E-mail:

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

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

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

KARTA MODUŁU KSZTAŁCENIA

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

Bardziej szczegółowo

Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane

Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane Nazwa modułu: Metodyki projektowania i modelowania systemów I Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3 Wydział: Informatyki, Elektroniki i Telekomunikacji Kierunek: Elektronika i Telekomunikacja

Bardziej szczegółowo

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

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

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

Lekkie metodyki. tworzenia oprogramowania

Lekkie metodyki. tworzenia oprogramowania Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz

Bardziej szczegółowo

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012 STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012 Program studiów opracował: Grzegorz Karpiuk CEL STUDIÓW 1. Zdobycie przez uczestników wiedzy i kompetencji z zakresu zarządzania projektami oraz

Bardziej szczegółowo

Bezpieczeństwo dziś i jutro Security InsideOut

Bezpieczeństwo dziś i jutro Security InsideOut Bezpieczeństwo dziś i jutro Security InsideOut Radosław Kaczorek, CISSP, CISA, CIA Partner Zarządzający w IMMUSEC Sp. z o.o. Radosław Oracle Security Kaczorek, Summit CISSP, 2011 CISA, Warszawa CIA Oracle

Bardziej szczegółowo

Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN

Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN Poznajmy Prowadzących Uczestników I oczekiwania. Agenda Wymagania Różne poziomy wymagań Kryteria jakości dla wymagań Specyfikacje http://edu.ittraining.pl/szkolenie/tworzenie_i_ocena_specyfikacji_wymaga

Bardziej szczegółowo

STUDIA PODYPLOMOWE Zarządzanie Projektami

STUDIA PODYPLOMOWE Zarządzanie Projektami STUDIA PODYPLOMOWE Zarządzanie Projektami (Program studiów) Opracowanie: dr inż. Jacek Jakieła Program studiów Zarządzanie projektami 2 CEL STUDIÓW, ADRESAT I PROFIL ABSOLWENTA Studia podyplomowe Zarządzanie

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

Certyfikowany Tester Syllabus dla Poziomu Zaawansowanego

Certyfikowany Tester Syllabus dla Poziomu Zaawansowanego Certyfikowany Tester Stowarzyszenie Jakości Systemów Informatycznych International Software Testing Qualifications Board Strona 1 z 159 Wszelkie prawa dla wersji angielskiej zastrzeżone dla International

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

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

Bardziej szczegółowo

Rozdział 4 Planowanie rozwoju technologii - Aleksander Buczacki 4.1. Wstęp 4.2. Proces planowania rozwoju technologii

Rozdział 4 Planowanie rozwoju technologii - Aleksander Buczacki 4.1. Wstęp 4.2. Proces planowania rozwoju technologii Spis treści Wprowadzenie Rozdział 1 Pojęcie i klasyfikacja produktów oraz ich miejsce w strategii firmy - Jerzy Koszałka 1.1. Wstęp 1.2. Rynek jako miejsce oferowania i wymiany produktów 1.3. Pojęcie produktu

Bardziej szczegółowo

Źródła dumy zawodowej testera oprogramowania

Źródła dumy zawodowej testera oprogramowania Źródła dumy zawodowej testera oprogramowania Tom Gilb & Kai Gilb: False QA is calling your activity QA when in fact you only do testing. http://www.result-planning.com/real+qa+manifesto Nie jestem QA!

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA

INŻYNIERIA OPROGRAMOWANIA INŻYNIERIA OPROGRAMOWANIA dr inż. Jerzy Sas e-mail: jerzy.sas@pwr.wroc.pl Wykład 1 (1) to zastosowanie systematycznego, zdyscypliniowanego ilościowego podejścia do prowadzenia projektu informatycznego

Bardziej szczegółowo

Podejście zwinne do zarządzania projektami

Podejście zwinne do zarządzania projektami Podejście zwinne do zarządzania projektami na przykładach projektów wytwarzania oprogramowania Wojciech Czujowski, Łukasz Sienkiewicz Tieto Poland Agenda CZĘŚĆ I-sza: Kilka słów o Tieto SCRUM w organizacji

Bardziej szczegółowo

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie. Inżynieria I Andrzej Jaszkiewicz Kontakt Andrzej Jaszkiewicz p. 8, CW Berdychowo tel. 66 52 933 ajaszkiewicz@cs.put.poznan.pl Rynek 2008 Świat 304 miliardy $ (451 miliardów 2013F) Bez wytwarzanego na własne

Bardziej szczegółowo

Metodyki zwinne wytwarzania oprogramowania

Metodyki zwinne wytwarzania oprogramowania Metodyki zwinne wytwarzania oprogramowania Wykład 1 Marcin Młotkowski 7 października 2014 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski

Bardziej szczegółowo

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

Zarządzanie projektem informatycznym, w3

Zarządzanie projektem informatycznym, w3 Zarządzanie zakresem projektu informatycznego Zarządzanie projektem informatycznym, w3 walery.suslow@ie.tu.koszalin.pl Cele projektu Rezultatem każdego zdefiniowanego projektu jest z założenia wprowadzenie

Bardziej szczegółowo

Monitorowanie i kontrola testów według modelu TMMi

Monitorowanie i kontrola testów według modelu TMMi Magazine Monitorowanie i kontrola testów według modelu TMMi Autor: Piotr Piotrowski O autorze: Inżynier Testów w Tieto Polska, gdzie zajmuje się: tworzeniem przypadków testowych, prostych planów testów,

Bardziej szczegółowo

Projektowanie oprogramowania

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

Bardziej szczegółowo

Sukces vs porażka. Sukces. Porażka

Sukces vs porażka. Sukces. Porażka Wstęp Cytaty Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program, to jest drobiazg. Często po awarii pojawia się komunikat typu ID 02. ID to skrót od idiotyczny drobiazg,

Bardziej szczegółowo