Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 2 Projekty informatyczne, a wymagania

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

Download "Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 2 Projekty informatyczne, a wymagania"

Transkrypt

1 Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 2 Projekty informatyczne, a wymagania Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)

2 Cele Definicje kluczowych pojęć zarządzania wymaganiami Identyfikacja czynników przyczyniających się do sukcesu lub porażki projektu: Zależność wpływu zarządzania wymaganiami na sukces projektu Opis jakości zbiorów wymagań: Weryfikowalność, traceability, jednoznaczność Podejście RUP: workflow, role i artefakty 2

3 Częste sytuacje... Zrobiliśmy wszystko, Ale nie wszystko, czego Pan wymaga Brak ł. analizy czego chciałem... problemu pod kątem potrzeb zleceniodawcy lub użytkowników Dlaczego nie Brak zrozumienia powiedziałe ś nam, wymagań i że chcesz mie ć t ą zaangażowania cech ę? zleceniodawcy lub użytkowników Nikt mnie nie zapyta ł! Hmm... Chyba chodziło im, żeby to działało jako ś w ten sposób... Deweloperzy wiedzą najlepiej, wymagania nie są sformalizowane, brak zarządzania zmianami Mam pomys ł na świetn ą now ą cech ę. Możesz to dorzuci ć? Nie ma sprawy! Brak zarządzania i koordynacji 3

4 Wymagania Potrzeby użytkowników PROBLEM Przestrzeń problemu traceability Własności Przypadki użycia i wymagania SYSTEM który ma zostać zbudowany Przestrzeń rozwiązania Procedury testowe Projekt Dokumentacja użytkownika 4

5 Wymagania Proces transformacji: Przeniesienie potrzeb zleceniodawcy/ użytkowników na zbiór cech systemu Cechy transformowane są w wymagania funkcjonalne i niefunkcjonalne Szczegółowe specyfikacje są przekształcane w procedury testowe, projekt (design) i dokumentację użytkownika 5

6 Wymagania Traceability pozwala na: Ocenę wpływu zmiany w wymaganiach na projekt Ocenę wpływu porażki testu na wymagania (jeżeli test się nie udaje, wymaganie raczej nie jest spełnione) Zarządzanie zakresem projektu Sprawdzenie, czy wszystkie wymagania są spełnione przez implementację Sprawdzenie, czy aplikacja robi tylko to, co zostało zamierzone Zarządzanie zmianami 6

7 Definicje Wymaganie: Warunek, który system musi spełniać lub zdolność, którą musi wykazywać (bezpośrednio na podstawie potrzeb użytkowników lub określone w umowie, standardzie specyfikacji, itp.) Pożądana cecha, własność lub zachowanie systemu Wymagania opisują raczej co system robi, a nie jak to robi (czarna skrzynka) 7

8 Definicje Zarządzanie wymaganiami to systematyczne podejście do: wyrażania, organizacji i dokumentowania wymagań uzyskiwania i utrzymywania porozumienia między klientami/użytkownikami, a zespołem projektowym w sprawach dotyczących zmian w wymaganiach. Zarządzanie wymaganiami odnosi sukces tylko kiedy dopuszcza dużą dozę niepewności we wczesnych stadiach projektu; jednocześnie zapewnia coraz lepszą definicję wymagań wraz z upływem czasu. 8

9 Co określają wymagania? SYSTEM wejścia? wyjścia Funkcje systemu Wymagania niefunkcjonalne (np. wydajność) Ograniczenia projektowe (np. środowisko) kontekst dla tego co system robi (minimalna wiedza techniczna konieczna do wyrażenia wymagań) 9

10 Definicje Żądanie/potrzeba klienta lub użytkownika Niezależne od rozwiązania wyrażenie pożądanego stanu w dziedzinie rozwiązania lub problemu Cecha Widoczna z zewnątrz usługa, poprzez którą system bezpośrednio wypełnia jedno lub więcej żądań. Wymagania oprogramowania Funkcjonalne specyfikują z perspektywy czarnej skrzynki, jak rozwiązanie współpracuje i komunikuje się ze światem zewnętrznym (interakcja) Niefunkcjonalne wyrażają z perspektywy czarnej skrzynki jakoś atrybutów rozwiązania Ograniczenie Obostrzenie nałożone na projekt systemu lub proces użyty do budowy systemu 10

11 Przykłady system zapisów na kursy Żądanie/potrzeba klienta lub użytkownika Cecha Mniej czynności administracyjnych podczas rejestracji Wykładowca potrzebuje natychmiastowego dostępu do ocen studentów Przeglądarka przedstawia informacje o studencie w formie drzewa, szeregując je według semestrów i przedmiotów Wymagania oprogramowania Funkcjonalne przypadek użycia rozpoczyna się w momencie, kiedy student wybiera w systemie zarządzania kursami opcję zapisu na kurs... Niefunkcjonalne system ma być dostępny 99% czasu w systemie 24/7 (3.65 dnia niedostępności w ciągu roku) Ograniczenie System ma pracować na uczelnianym mainframe'ie DEC VAX 11

12 Zależność definicji Typy wymagań Cechy Żądania/potrzeby klienta Wymagania oprogramowania Ograniczenia projektowe Wymagania funkcjonalne Wymagania niefunkcjonalne 12 Leffingwell & Widrig, 1999

13 Zależność definicji D. Hatley, P. Hruschka and I. Pirbhai Process for System Architecture and Requirements Engineering" 13

14 Dlaczego zarządzanie wymaganiami stanowi problem? Wymagania:... Zazwyczaj nie są oczywiste lub klienci nie wiedzą czego chcą Pochodzą z wielu źródeł Nie zawsze można je wyrazić prostymi słowami lub analitycy nie potrafią opisać ich w sposób zrozumiały dla zwykłych ludzi Odnoszą się do siebie nawzajem i do innych produktów procesu inżynierii wymagania Mają unikatowe właściwości lub ich wartości Zmieniają się Są trudne to kontrolowania wraz ze wzrostem ich liczby 14

15 Zarządzanie wymaga strategii (1) Plan zarządzania wymaganiami (requirement management plan, plan RM): Powinien zostać opracowany w celu określenia informacji (i mechanizmów kontrolujących), które są zbierane i wykorzystywane to pomiarów, raportowania i kontrolowania zmian w wymaganiach Przed przystąpieniem do opisu wymagań projektu, należy zdecydować, jak je dokumentować i organizować Należy także zdecydować jak używać atrybutów wymagań podczas zarządzania wymaganiami wraz z rozwojem projektu Plan RM dokumentuje wszystkie decyzje odnośnie dokumentów wymagań, typów wymagań, wskazówki i strategie dla atrybutów wymagań i śledzenie wymagań (traceability) 15

16 Zarządzanie wymaga strategii (2) Podobnie jak słownik, plan RM jest żyjącym dokumentem. Jego rozwój rozpoczyna się wraz z początkiem projektu. Nowe pozycje są dodawane w miarę podejmowania kolejnych decyzji. W idealnej sytuacji, można użyć standardowego planu, przystosowywanego do specyfiki każdego projektu. Pozwala to przyspieszyć fazę rozpoczęcia (inception) projektu. Co znajduje się w planie RM: Typy wymagań, które zbieramy i gdzie będą zbierane, Typy atrybutów do śledzenia, Typy wymagań do śledzenia, Typy dokumentów do wytworzenia, Wytyczne do zarządzania. 16

17 Dlaczego należy dbać o właściwe zarządzanie wymaganiami?

18 Efektywne zarządzanie wymaganiami Utrzymywanie klarownych i jasno wyrażonych wymagań poprzez: Dobrą jakość wymagań, Atrybuty stosowalne do każdego typu wymagań, Traceability do innych wymagań i artefaktów projektu. Celem jest dostarczenie wysokiej jakości produktu w założonym czasie i budżecie, który spełni rzeczywiste wymagania klienta. 18

19 Co stanowi o jakości produktu? Stare podejście (delivered as specified): Zgadza się z dokumentami wymagań, Przechodzi testy, Rozwój (development) oparty na procesie, Oparte na czynnościach. Współczesne rozumienie: Zrozumienie wszystkich potrzeb użytkowników, Ciągła ocena, czy wszystkich artefaktów pod kątem spełniania potrzeb, Oparte na rezultatach. 19

20 Wymiary jakości FURPS (1) Functionality (funkcjonalność) Usability (użyteczność) Reliability (niezawodność) Performance (wydajność) Supportability (zarządzalność) Podstawowe zdolności, bezpieczeństwo, ogólność Estetyka (subiektywny czynnik ludzki), spójność, dokumentacja Częstotliwość/dotkliwośc błędów, podnoszenie po błędzie, przewidywalność, dokładność, MTBF* Szybkość, sprawność, zużycie zasobów, przepustowość, czas odpowiedzi Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Robustness 20 *) Mean Time Between Failures Grady, 1992

21 Wymiary jakości FURPS (2) Skrót FURPS oznacza tą część typów wymagań, których należy szukać Przypomina, że ważne są zarówno wymagania niefunkcjonalne (URPS), jak i funkcjonalne (behawioralne) Często stosowany FURPS+ oznacza rozszerzenie tych typów o wymagania nie objęte żadną z pięciu kategorii:...? 21

22 Na czas i w założonym budżecie (1) zasoby ZAKRES Ile pracy możemy wykonać? budżet czas 22

23 Na czas i w założonym budżecie (2) Ponieważ czas i zasoby (ludzie, fundusze, wyposażenie, itp.) są ograniczone, może wykonać tylko określony zakres prac Żeby dostarczyć produkt na czas i w budżecie, należy określić, ile pracy możemy naprawdę wykonać w ramach danego zakresu (scope), czasu, zasobów i środków finansowych Jeżeli którykolwiek z czynników się zmienia, trzeba wykonać odpowiednie dopasowania, na przykład: jeżeli powiększymy zakres, należy zwiększyć jedno z pozostałych (budżet, czas lub zasoby), jeżeli ograniczymy budżet, musimy zmniejszyć zakres przeprowadzonych prac w tym samym czasie oraz dostępne zasoby. Porażka przytrafia się najczęściej, jeżeli staramy się wcisnąć coraz więcej w zakres, nie przesuwając pozostałych punktów aby to skompensować W celu dostarczenia maksymalnej wartości należy być możliwie najbardziej dokładnym w szacunkach zasoby ZAKRES 23 budżet czas

24 Spełnić rzeczywiste potrzeby klientów (1) Cecha 1: System musi... Cecha 2: System musi... Cecha 3: System będzie... Cecha 4: System musi... Cecha 5: System powinien... Cecha 6: System musi Cecha 7: System musi... Cecha n: System powinien... Data rozpoczęcia projektu Zamierzona data wydania czas 24

25 Spełnić rzeczywiste potrzeby klientów (2) W jaki sposób uzyskujemy porozumienie na temat cech, które mają zostać włączone do projektu? Jakie potrzeby klientów one reprezentują? W jaki sposób powinny one zostać spriorytetyzowane? Co powinno znaleźć się w ramach dostarczonego produktu (delivery baseline)? Zbiór cech, które stanowią uzgodnioną podstawę dla dalszych prac, który może zostać zmodyfikowany tylko poprzez formalną procedurę 25

26 Wymagania umożliwiają porozumienie (1) Cel Klient użytkownicy System który ma zostać zbudowany Weryfikacja wymagań Cel pośredni (zastępczy) Wymagania 26

27 Wymagania umożliwiają porozumienie (2) Specyfikacja wymagań stanowi wyrażenie porozumienia, dotyczącego budowanego systemu Ponieważ zazwyczaj rzadko mamy kontakt z klientem/użytkownikami oraz niektórzy klienci często zmieniają zdanie, porozumienie należy udokumentować Specyfikacja wymagań stanowi proxy klienta powinna zawierać wszystko co jest potrzebne, aby wyeliminować potrzebę późniejszych zbędnych kontaktów w fazie implementacji Forma wyrażenie wymagań powinna być zrozumiała dla obydwu stron; wymagania: Stanowią zastępczy cel dla zespołu deweloperskiego Są podstawą walidacji i kryteriami akceptacji gotowego systemu przez klienta 27

28 Jakie czynniki przyczyniają się do sukcesu projektu? 28 % projektów zostaje ukończonych na czas i w zakładanym budżecie 49 % projektów wykracza poza wstępne szacunki: Przekroczenie czasu średnio o 63 % Przekroczenie kosztów średnio o 45 %. 23 % projektów zostaje porzuconych przed ukończeniem Zarządzanie wymaganiami The CHAOS ten: 1. Executive Management Support 2. User Involvement 3. Experienced Project Manager 4. Clear Business Objectives 5. Minimized Scope 6. Standard Software Infrastructure 7. Firm Basic Requirements 8. Formal Methodology 9. Reliable Estimates 10. Other Standish Group's CHAOS report of (www.standishgroup.com) 28

29 Rozmiar ma znaczenie... (1) Wskaźnik sukcesu (%) less than $750K $750K to $1.5M $1.5M to $3M $3M to $6M $6M to $10M Over $10M 0 Project Size ($) Standish Group, 99 (www.standishgroup.com) 29

30 Rozmiar ma znaczenie... (2) Pozornie większe projekty mają większe zespoły i lepszą organizację oraz zarządzanie, czyli większą szansę na powodzenie W rzeczywistości jest odwrotnie Zalety mniejszych projektów: Mniejsze zespoły Mniej wymagań Mniej problemów z komunikacją Łatwiejsze w zarządzaniu Bardziej skupione na celach biznesowych 30

31 Wysoki koszt błędów w wymaganiach Reguła Wymagania Projekt Kodowanie Testy jednostkowe Testy akceptacyjne Utrzymanie 200:1 Średni stosunek kosztów to 14:1 (Grady, 1989) Względny koszt naprawy błędów: Kiedy wprowadzony do kiedy naprawiony Reguła obowiązuje dla modelu kaskadowego, jednak w procesie iteracyjnym koszty także są olbrzymie. 31 Boehm, 1988

32 Jak pomóc projektowi osiągnąć sukces? Analiza problemu Zrozumienie problemu Uzyskanie porozumienia z klientem Klarowne wyrażenie celi biznesowych Sprecyzowanie wymagań Identyfikacja, kto korzysta z systemu (aktorzy) Określenie, jak system jest używany (przyp. użycia) Zarządzanie wymaganiami Kompletna specyfikacja wymagań Zarządzanie oczekiwaniami, zmianami i błędami Kontrola rozpełzania się zakresu (feature creep) Ścisłe określenie składu zespołu 32

33 Uczestniczyć powinien cały zespół Deweloperzy, testerzy i pisarze dokumentacji Pomoc w osiągnięciu odpowiednich praktyk zarządzanie wymaganiami Monitorowanie zgodności z praktykami Weryfikacja procesu rozumowania i wyrażania Dokumentowanie wymagań Uczestnictwo w przeglądach wymagań Uczestnictwo bądź przewodnictwo w CCB (Change Control Board) Przeglądy efektów traceability Weryfikacja jakości, testowalności i zupełności. 33

34 Wartość zależna jest od jakości

35 Wartość zmniejsza się w miarę ustępstw w jakości???? 35

36 Wartość zmniejsza się w miarę ustępstw w jakości Jakość można mierzyć na wiele sposobów (np. dostępność systemu, błędy, czasy odpowiedzi) Kolejnym wymiarem jakości jest jakość zbioru wymagań Celem jest spełnienie potrzeb klienta: Wraz ze spadkiem jakości, zdolność spełnienia tych potrzeb także spada Jeżeli system ich nie spełnia, jego wartość się obniża Powyższe przykłady jakości są obserwowalne w działającym systemie. Stanowią efekt implementacji wymagań: System nie może być lepszy niż wymagania użyte do jego specyfikacji 36

37 Jakość zbioru wymagań (1) Poprawny Czy stwierdzenie, że system musi coś robić jest prawdziwe? Czy każde wymaganie opisuje coś, co system musi robić? (Davis, 1993) 37 Leffingwell & Widrig (1999)

38 Jakość zbioru wymagań (2) Zupełny Czy opisuje wszystkie istotne wymagania, na których zależy użytkownikowi? Czy pokrywa nie tylko funkcjonalności, ale także wydajność, ograniczenia projektowe, atrybuty, czy interfejsy zewnętrzne? Czy wszystkie zakresy wartości wejściowych (ze wszystkich możliwych scenariuszy) zostały zidentyfikowane? Czy wszystkie tabele, ilustracje i diagramy są w pełni opisane, posiadają poprawne odniesienia i definicje pojęć oraz jednostek? 38 Leffingwell & Widrig (1999)

39 Jakość zbioru wymagań (3) Spójny Czy nie istnieją konflikty między wymaganiami? Czy nie istnieją konflikty między dokumentami (np. diagramem UC, a specyfikacją uzupełniającą)? 39 Leffingwell & Widrig (1999)

40 Jakość zbioru wymagań (4) Jednoznaczny Czy możliwa jest wyłącznie jedna interpretacja każdego wymagania? Czy w wątpliwych przypadkach wprowadzono odpowiednie diagramy, ilustracje i przykłady? Czy charakterystyczne dla dziedziny biznesowej lub wieloznaczne słowa i zwroty zostały prawidłowo zdefiniowane w słowniku? Przykład: Mary had a little lamb 40 Leffingwell & Widrig (1999)

41 Jakość zbioru wymagań (4a) Have Lamb Interpretation 1a 1a Mary owned a little sheep under one year of age or without permanent teeth. 4a 1a Mary acquired a little sheep under one year of age or without permanent teeth. 5a 1a Mary is the person who owned a little sheep under one year of age or without permanent teeth. 10a 1a Mary held a little sheep under one year of age or without permanent teeth in a position of disadvantage. 10b 1a Mary tricked a little sheep under one year of age or without permanent teeth. 12 1b Mary gave birth to a young antelope. 12 2a Mary is (or was) the mother of a particular small, gentle person. 13 3a Mary ate a little of the flesh of lamb. 14 2c Mary bribed a small person trading in securities who was easily cheated. Przykład: Mary had a little lamb 1a: To hold in possession as property 4a: To acquire or get possession of: OBTAIN (best to be had) 4c: ACCEPT; to have in marriage 5a: To be marked or characterized by (have red hair) 10a: To hold in a position of disadvantage or certain defeat 10b: TRICK, FOOL (been had by a partner) 12: BEGET, BEAR (have a baby) 13: To partake of (have dinner) 14: BRIBE, SUBORN (can be had for a price) 1a: A young sheep esp. less than one year old or without permanent teeth 1b: The young of various other animals (as smaller antelopes) 2a: A person as gentle or weak as a lamb 2b: DEAR, PET 2c: A person easily cheated or deceived especially in trading securities 3a: The flesh of lamb used as food 41

42 Jakość zbioru wymagań (4b) Zbyt daleko posunięta jednoznaczność w wymaganiach często obniża ich zrozumienie i alienuje klientów i użytkowników Całkowite usunięcie niejednoznaczności można osiągnąć np. przez użycie wzoru matematycznego, co jednak uczyni wymaganie nieczytelnym dla większości odbiorców Celem jest odnalezienie złotego środka Zrozumiałość 42 Niejednoznaczność

43 Jakość zbioru wymagań (5) Weryfikowalny Czy może być skończonym kosztem zweryfikowany przez człowieka lub maszynę? Czy każde wymaganie jest weryfikowalne? Przykłady czy te stwierdzenia są weryfikowalne? Jeżeli nie, jak można je lepiej wyrazić? System obsługuje do 1000 użytkowników jednocześnie System powinien odpowiedzieć na dowolne zapytanie w 500 ms Kolor powinien być łagodnym odcieniem zieleni System musi być dostępny 24/7 System musi eksportować dane w formacie CSV 43 Leffingwell & Widrig (1999)

44 Jakość zbioru wymagań (6) Oznaczony pod względem ważności i stabilności Czy może być posortowany według ważności dla klienta i stabilności samych wymagań? Czy każde wymaganie zostało oznaczone w odpowiedni sposób? 44 Leffingwell & Widrig (1999)

45 Jakość zbioru wymagań (7) Modyfikowalny Czy zmiany nie wpływają na strukturę i styl zbioru? Czy zidentyfikowano nadmiarowość, zminimalizowano ją i użyto w zamian odniesień? 45 Leffingwell & Widrig (1999)

46 Żądania/potrzeby Jakość zbioru wymagań (8) Cechy Traceable Czy można odnaleźć początek i powód każdego wymagania? Czy przyczyna wymagania jest jasna? Przypadki użycia Czy każde wymaganie ma czytelny identyfikator? Czy jest ono odróżnione od drugorzędnych stwierdzeń w zbiorze wymagań? Czy istnieje backward traceability dostępna poprzez jawne odwołanie do poprzednich artefaktów? Czy istnieje forward traceability dla artefaktów wynikających ze zbioru wymagań (np. dla przypadków testowych)? Dokumenty uzupełniające 46 Leffingwell & Widrig (1999)

47 Jakość zbioru wymagań (9) Zrozumiały Czy zbiór jest zrozumiały dla klienta i deweloperów? Czy w wątpliwych przypadkach wprowadzono odpowiednie diagramy, ilustracje i przykłady? Czy charakterystyczne dla dziedziny biznesowej lub wieloznaczne słowa i zwroty zostały prawidłowo zdefiniowane w słowniku? 47 Leffingwell & Widrig (1999)

48 RUP jako framework do zarządzania wymaganiami 48

49 Workflow dyscypliny Requirements 49

50 Role i artefakty 50

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

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

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

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements

Bardziej szczegółowo

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 4 Zrozumienie stron zainteresowanych

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 4 Zrozumienie stron zainteresowanych Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 4 Zrozumienie stron zainteresowanych Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management

Bardziej szczegółowo

Tworzenie przypadków testowych

Tworzenie przypadków testowych Tworzenie przypadków testowych Prowadząca: Katarzyna Pietrzyk Agenda 1. Wprowadzenie 2. Wymagania 3. Przypadek testowy Definicja Schemat Cechy dobrego przypadku testowego 4. Techniki projektowania Czarnej

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

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

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

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

Zagadnienia (1/3) Inżynieria Oprogramowania

Zagadnienia (1/3) Inżynieria Oprogramowania Zagadnienia (1/3) Pozyskiwanie i analiza Reprezentacje na poszczególnych etapach projektu Najczęściej pojawiające się problemy podczas pozyskiwania oraz metody ich rozwiązywania Reprezentacja z punktu

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Od pomysłu do podpisania umowy. Izabela Adamska

Od pomysłu do podpisania umowy. Izabela Adamska Od pomysłu do podpisania umowy Izabela Adamska Restauracja Czy jest równowaga pomiędzy tym ile klient zapłaci, a tym co otrzyma w zamian? =? Sprawdźmy czy to jest proste? Wymagania telefonu komórkowego:

Bardziej szczegółowo

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

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

Proces projektowania i wdrożenia serwisu internetowego

Proces projektowania i wdrożenia serwisu internetowego Proces projektowania i wdrożenia serwisu internetowego Kluczowe etapy projektu 9 1 Rozwój i optymalizacja Analiza celów, potrzeb i konkurencji 8 Szkolenie IMPROVE THINK Wireframe i prototyp (UX) 2 7 Testy

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

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

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

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

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

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

UPEDU: Testowanie (ang. Testing discipline)

UPEDU: Testowanie (ang. Testing discipline) Wydział Informatyki PB Wprowadzenie Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 9: UPEDU: Testowanie (ang. Testing discipline) Dwa

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

Inżynieria oprogramowania (Software Engineering) Wykład 1

Inżynieria oprogramowania (Software Engineering) Wykład 1 Inżynieria oprogramowania (Software Engineering) Wykład 1 Wprowadzenie do inżynierii oprogramowania Zarządzanie przedmiotem Wydział: WEiI Katedra: KIK Web site: http://moskit.weii.tu.koszalin.pl/~swalover/

Bardziej szczegółowo

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.

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

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

Normalizacja baz danych

Normalizacja baz danych Normalizacja baz danych Definicja 1 1 Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi

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

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

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

Użyteczność stron internetowych

Użyteczność stron internetowych Użyteczność stron internetowych Użyteczność Użyteczność (ang. usability) jest to dziedzina wiedzy dotycząca interaktywnych urządzeń i aplikacji, która określa stopień, w jakim ludzie są w stanie wykonać

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

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

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

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

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

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10.

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10. Bez celu ani rusz Karolina Zmitrowicz Niepowodzenia projektów informatycznych to nieustannie wdzięczny temat pojawia się na konferencjach, szkoleniach, w prasie i innych publikacjach. Badaniem przyczyn

Bardziej szczegółowo

Inżynieria Oprogramowania. Robert Szmurło

Inżynieria Oprogramowania. Robert Szmurło Robert Szmurło 1 Złożoność inżynierii oprogramowania Programowanie komputerowy jest zdecydowanie najbardziej skomplikowanym zadaniem intelektualnym podejmowanym przez człowieka. Kiedykolwiek. Gerald M.

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

Inżynieria oprogramowania wykład IV Faza określenia wymagań

Inżynieria oprogramowania wykład IV Faza określenia wymagań Inżynieria oprogramowania wykład IV Faza określenia wymagań prowadzący: dr inż. Krzysztof Bartecki Faza określenia wymagań Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza

Bardziej szczegółowo

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2 Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się

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

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

Overlord - Software Development Plan

Overlord - Software Development Plan Overlord - Software Development Plan Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 5 czerwca 2006 Spis treści 0.1 Cel.......................................... 4 0.2 Zakres........................................

Bardziej szczegółowo

Rozpoczęcie, inicjacja (ang. inception

Rozpoczęcie, inicjacja (ang. inception Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

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

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

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań 2012 Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań Mateusz Kurleto NEOTERIC Wdrożenie systemu B2B Lublin, 25 października 2012 Mateusz Kurleto Od 2005 r. właściciel NEOTERIC,

Bardziej szczegółowo

dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach Koszt Wartość

dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach Koszt Wartość Wykład Zarządzanie projektami Zajęcia 4 Zarządzanie jakością w projekcie dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Zarządzanie projektami IT

Zarządzanie projektami IT Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie

Bardziej szczegółowo

Raport oceny kompetencji

Raport oceny kompetencji Symulacje oceniające kompetencje Raport oceny kompetencji Rut Paweł 08-01-2015 Kompetencje sprzedażowe dla efactor Sp. z o.o. Dane osobowe Rut Paweł CEO pawel.rut@efactor.pl more-than-manager.com 2 z 13

Bardziej szczegółowo

Scaling Scrum with SAFe. Małgorzata Czerwińska

Scaling Scrum with SAFe. Małgorzata Czerwińska Scaling Scrum with SAFe Małgorzata Czerwińska Agenda 1. Wstęp 2. Współpraca zespołów scrumowych 3. Zarządzanie Programem 4. Podsumowanie Wstęp Skuteczność zespołów developerskich, realizujących projekty

Bardziej szczegółowo

Proces Inżynierii Wymagań

Proces Inżynierii Wymagań Proces Inżynierii Wymagań michał możdżonek 02.2008 Literatura 1. Sommerville I. (2003): Inżynieria oprogramowania, WNT, Warszawa 2. Leffingwell D., Widrig D. (2003): Zarządzanie wymaganiami, WNT, Warszawa

Bardziej szczegółowo

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/ IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/ Faza określania wymagań (1) Cel fazy określania wymagań dokładne ustalenie wymagań klienta

Bardziej szczegółowo

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

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

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

BAKER TILLY POLAND CONSULTING

BAKER TILLY POLAND CONSULTING BAKER TILLY POLAND CONSULTING Wytyczne KNF dla firm ubezpieczeniowych i towarzystw reasekuracyjnych w obszarze bezpieczeństwa informatycznego An independent member of Baker Tilly International Objaśnienie

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

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

Ćwiczenie 1. System jakości w laboratorium oceny żywności

Ćwiczenie 1. System jakości w laboratorium oceny żywności Ćwiczenie 1. System jakości w laboratorium oceny żywności Powszechnie przyjmuje się, że każde laboratorium, które chce reprezentować wiarygodne dane musi wdrożyć odpowiednie procedury zapewnienia jakości.

Bardziej szczegółowo

Human Performance Improvementjak HR może podnieść efektywność organizacyjną firmy

Human Performance Improvementjak HR może podnieść efektywność organizacyjną firmy Human Performance Improvementjak HR może podnieść efektywność organizacyjną firmy Katarzyna Meysztowicz k.meysztowicz@tangerine.biz.pl Tel.: 790 300 575 Agenda Od czego zależy efektywność organizacyjna

Bardziej szczegółowo

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

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

Bardziej szczegółowo

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

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

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

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

Bardziej szczegółowo

Przypadki bez przypadków. Jak dobierać scenariusze testowe.

Przypadki bez przypadków. Jak dobierać scenariusze testowe. Przypadki bez przypadków. Jak dobierać scenariusze testowe. Konferencja SQAM 2008 Warszawa, 29. kwietnia Wojciech Pająk 29 kwietnia 2008 Warszawa Zagadnienia prezentacji 1. Wprowadzenie 2. Definicje przypadków

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej.

Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej. Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej. Andrzej Hantz Dyrektor Centrum Metrologii RADWAG Wagi Elektroniczne Pomiary w laboratorium

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

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

Architektura oprogramowania w praktyce. Wydanie II.

Architektura oprogramowania w praktyce. Wydanie II. Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?

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

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS Andrzej Zalewski, Marcin Szlenk, Szymon Kijas a.zalewski@elka.pw.edu.pl s.kijas@elka.pw.edu.pl Praca naukowa finansowana ze środków budżetowych na naukę

Bardziej szczegółowo

Cykle życia systemu informatycznego

Cykle życia systemu informatycznego Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów

Bardziej szczegółowo

Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera

Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera Zarządzanie projektami najlepsze światowe praktyki mgr Marcin Gałuszka Zajęcia 2 - Wrocław, 28.01.2012 AGENDA

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

Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów

Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów Specyfikacja procesów biznesowych SPIS TREŚCI 1 Wstęp... 4 1.1 Przeznaczenie dokumentu...

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

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