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

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

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

Specyfikacja dodatkowa. Wersja <1.0>

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0> Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą

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

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

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

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

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

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

Bardziej szczegółowo

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

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

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

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

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

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

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

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

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

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

wbudowane October 7, 2015 KSEM WETI PG Komputery przemysłowe i systemy wbudowane Oprogramowanie systemów wbudowanych - wydajność Wydajność

wbudowane October 7, 2015 KSEM WETI PG Komputery przemysłowe i systemy wbudowane Oprogramowanie systemów wbudowanych - wydajność Wydajność KSEM WETI PG October 7, 2015 Inżynieria wydajności oprogramowania Software performance engineering (SPE) - dyscyplina zajmująca się poprawą dojrzałości procesu budowy i rozwoju dla zwiększenia ich wydajności.

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

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

Jak opisać wymagania zamawiającego wybrane elementy

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

Bardziej szczegółowo

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

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

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

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7 AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli

Bardziej szczegółowo

Wytwórstwo oprogramowania. michał możdżonek

Wytwórstwo oprogramowania. michał możdżonek Wytwórstwo oprogramowania michał możdżonek 01.2008 Plan wykładu 1. Proces tworzenie oprogramowania 2. Zarządzanie projektami 3. Wymagania 4. Projektowanie 5. Testowanie 6. Szacowanie złożoności i kosztu

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

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

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

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

Zakres prac implementacja VPLEX i ViPR dla środowiska macierzy VNX 5800

Zakres prac implementacja VPLEX i ViPR dla środowiska macierzy VNX 5800 Zakres prac implementacja VPLEX i ViPR dla środowiska macierzy VNX 5800 Autor: RWE GBS Polska Wersja: 1.0 Status: opublikowany Copyright RWE GBS. Any use or form of reproduction, in whole or part, of any

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

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

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

Jak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody?

Jak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody? Modelowanie biznesowe Wprowadzenie (część 1) Co to jest? Każdy model jest błędny. Niektóre modele są użyteczne. George E. P. Box Jak firma generuje przychody? Model biznesowy Sposób generowania przychodów

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków

Bardziej szczegółowo

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie

Bardziej szczegółowo

Programowanie zespołowe

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

Bardziej szczegółowo

Faza Określania Wymagań

Faza Określania Wymagań Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie

Bardziej szczegółowo

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

Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia

Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia Program szkolenia: Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Testowanie aplikacji mobilnych na

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

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

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

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

Wprowadzenie do Behaviordriven

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

Bardziej szczegółowo

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

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

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

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

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

Bardziej szczegółowo

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

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

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

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

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

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

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

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania 2/31 Wprowadzenie Syndrom LOOP Late Późno Over budget Przekroczono budżet Overtime nadgodziny

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

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

Konwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008

Konwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008 Konwerter Plan testów Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008 1 Spis treści 1 Wprowadzenie 3 1.1 Cel........................................ 3 1.2 Zamierzeni odbiorcy

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

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

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

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Zarządzanie projektami. Wykład 2 Zarządzanie projektem Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów

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

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

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

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

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

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

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

Ć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

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

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

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

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

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

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

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

Cele przedsięwzięcia

Cele przedsięwzięcia Określanie wymagań Cele przedsięwzięcia Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

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

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

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

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

Poziomy zarządzania projektem w odniesieniu do ról i odpowiedzialności

Poziomy zarządzania projektem w odniesieniu do ról i odpowiedzialności Poziomy zarządzania projektem w odniesieniu do ról i odpowiedzialności Ewa Szczepańska Warszawa, dnia 22 maja 2012 r. Agenda Zarządzanie strategiczne Zarządzanie operacyjne Dostarczanie produktów Role

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