Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 2 Projekty informatyczne, a wymagania
|
|
- Julian Dąbrowski
- 8 lat temu
- Przeglądów:
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 ( 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 ( 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 Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoModelowanie 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ółowoWstę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ółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoMaciej 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ółowoInż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ółowoUPEDU: Rozpoznanie wymagań (ang. requirements discipline)
Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 5: UPEDU: Rozpoznanie wymagań (ang. requirements discipline) Na podstawie podręcznika:
Bardziej szczegółowoInż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<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ółowoJakość w procesie wytwarzania oprogramowania
Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Inżyniera wymagań Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoTworzenie 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ółowoAnalityk 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ółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoInż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ółowoInż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ółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoInż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ółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoTestowanie 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ółowoKarta 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ółowoOd 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ółowoEtapy ż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ółowoInż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ółowoISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania
ISO 9000/9001 Jarosław Kuchta Jakość Oprogramowania Co to jest ISO International Organization for Standardization największa międzynarodowa organizacja opracowująca standardy 13700 standardów zrzesza narodowe
Bardziej szczegółowoWstę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ółowoREQB 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ółowoZagadnienia (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ółowo020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła
020 ANALIZA WYMAGAŃ Prof. dr hab. Marek Wisła Wymagania Wymaganie (ang. requirement) - pojęcie wymagania jest różnie interpretowane przez różne organizacje zajmujące się produkcją oprogramowania. Może
Bardziej szczegółowoZakres 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ółowoSCRUM 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ółowoProces 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ółowoProjektowanie 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ółowowbudowane 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ółowoJę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ółowoProjekt 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ółowoWstę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ółowoAnaliza 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ółowoWstę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ółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie x 1 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoWytwó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ółowoZasady 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ółowoZarządzanie konfiguracją produktu w całym cyklu Ŝycia. Aleksandra Grzywak-Gawryś Warsztaty Rola IRIS w branŝy kolejowej
Zarządzanie konfiguracją produktu w całym cyklu Ŝycia Aleksandra Grzywak-Gawryś Warsztaty Rola IRIS w branŝy kolejowej - plan prezentacji 1 2 3 4 5 Zarządzanie konfiguracją - definicje Problemy z konfiguracją
Bardziej szczegółowoMSF. 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ółowoJak 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ółowoProjektowanie 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ółowoKuchta Jarosław Jakość Oprogramowania. Modele dojrzałości procesu wytwarzania oprogramowania CMM/CMMI
Kuchta Jarosław Jakość Oprogramowania Modele dojrzałości procesu wytwarzania oprogramowania CMM/CMMI Krótka historia CMM/CMMI 1986 Software Engineering Institute (SEI) - schemat dojrzałości procesu wytwarzania
Bardziej szczegółowoMetodyka 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ółowoHP 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ółowoModelowanie 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ółowoProgramowanie 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ółowoMODELE 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ółowoOceny z prezentacji INKU011S. Zofia Kruczkiewicz
Oceny z prezentacji INKU011S Zofia Kruczkiewicz Data Student Oceny Uwagi 22.10.2017 231085 3.0 Przedstaw idealne środowisko do stosowania inżynierii oprogramowania- opisz elementy tego środowiska (sprzęt
Bardziej szczegółowoJak 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ółowoFaza 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ółowoInżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Inżynieria wymagań Jarosław Kuchta Cele inżynierii wymagań Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań
Bardziej szczegółowoProjektowanie BAZY DANYCH
Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoSYSTEMY INFORMATYCZNE ćwiczenia praktyczne
SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego
Bardziej szczegółowoTechnologia programowania
Wykład 1 2 październik 2018 Cel kursu Znacie język programowania oraz umiecie tworzyć proste aplikacje. Nie macie doświadczenia w tworzeniu dużych i złożonych systemów. Aby stworzyć duży system należy:
Bardziej szczegółowoPodstawy 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ółowoZakres 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ółowoINŻ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ółowoAUREA 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ółowoWprowadzenie 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ółowoCechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz
Cechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz Zofia Kruczkiewicz Wyklad_INP002017_3 1 CMMI (Capability Maturity Model Integration ) -
Bardziej szczegółowoInż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ółowoProcesowa 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ółowoNormalizacja 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ółowoTestowanie 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ółowoRAPORT 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ółowoZarzą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ółowoWszystkie 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ółowoInż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ółowoIO - 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ółowoKoszty 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ółowoZarzą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ółowoUż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ółowoPYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Bardziej szczegółowoNie 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ółowoJak 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ółowoDobre 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ółowoFeature 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ółowoUPEDU: 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ółowoZarzą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ółowoDwuwymiarowy sposób na podróbki > 34
TEMAT NUMERU I Bezpieczeństwo WIELE WYMIARÓW BEZPIECZEŃSTWA I zapobieganie zanieczyszczeniom krzyżowym I walka z fałszowaniem leków I walidacja rozwiązań chmurowych Maszyny rozwoju > 20 Dwuwymiarowy sposób
Bardziej szczegółowoMetody 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ółowoISO 9001:2015 przegląd wymagań
ISO 9001:2015 przegląd wymagań dr Inż. Tomasz Greber (www.greber.com.pl) Normy systemowe - historia MIL-Q-9858 (1959 r.) ANSI-N 45-2 (1971 r.) BS 4891 (1972 r.) PN-N 18001 ISO 14001 BS 5750 (1979 r.) EN
Bardziej szczegółowoProjekt: 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ółowoSpis 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ółowoKARTA 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ółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie. x 3 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoCompuware 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ółowoZARZĄ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ółowoSzablon 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ółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowo