020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła

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

Download "020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła"

Transkrypt

1 020 ANALIZA WYMAGAŃ Prof. dr hab. Marek Wisła

2 Wymagania Wymaganie (ang. requirement) - pojęcie wymagania jest różnie interpretowane przez różne organizacje zajmujące się produkcją oprogramowania. Może oznaczać zarówno bardzo zgrubny, abstrakcyjny opis funkcji jakie powinien realizować system informatyczny lub ograniczeń jakim może podlegać, jak również może być matematyczną formułą, bardzo precyzyjnie określającą jego funkcjonalność Wymagania w wielu przypadkach mogą spełniać różne, wydawałoby się przeciwstawne, funkcje: mogą stanowić podstawę dla ofert na realizację systemu - powinny być otwarte, tak aby nie narzucać formy realizacji systemu mogą (a właściwie powinny) stanowić podstawę kontraktu na realizację systemu - powinny zatem być: dokładne, kompletne, spójne, realizowalne i weryfikowalne

3 Inżynieria wymagań Inżynieria wymagań - proces identyfikacji wymagań jakich spełnienia oczekują użytkownicy systemu oraz ograniczeń nakładanych na jego realizację i użytkowanie.

4 Proces (uproszczony) inżynierii wymagań

5 Analiza realizowalności Analiza realizowalności zebranie zasadniczych (podstawowych) wymagań klienta i określenie czy te wymagania mogą zostać spełnione w założonym budżecie i przy wykorzystaniu wymaganych lub dostępnych rozwiązań technologicznych. Zwykle za ten etap klient nie jest obciążany kosztami. Jednak w przypadku dużych, złożonych projektów analiza realizowalności może być płatna.

6 Analiza wymagań Analiza wymagań analiza aktualnego środowiska pracy użytkowników systemu, określenie celów systemu i jego ograniczeń. Analiza wymagań jest zwykle wykonywana w środowisku klienta na podstawie bezpośrednich rozmów z decydentami i użytkownikami systemu. Analiza wymagań powinna być przeprowadzana kilkukrotnie w celu usunięcia zauważonych nieścisłości i ostatecznego uzgodnienia listy wymagań. Na podstawie przeprowadzonej analizy powstaje dokument definicja wymagań, który w formie przejrzystej i zrozumiałej przez przyszłych użytkowników systemu przedstawia zebrane wymagania i ograniczenia. Ten dokument powinien zostać zaakceptowany przez klienta.

7 Specyfikacja wymagań systemowych Specyfikacja Wymagań Systemowych (SWS, ang, System Requirements Specification - SRS) to dokument, w którym są uszczegółowiane wymagania dotyczące przyszłego systemu. Specyfikacja wymagań powinna stanowić podstawę kontraktu (wycena, termin realizacji) pomiędzy klientem i wykonawcą, jak również stanowi punkt startowy dla dokumentów określających architekturę systemu oraz jego implementację. Więcej o dokumentach SWS w dalszej części wykładu.

8 Przykład definicji i specyfikacji Definicja wymagania Oprogramowanie powinno w łatwy, intuicyjny sposób umożliwiać dostęp do zewnętrznych plików tworzonych przez inne programy. Specyfikacja wymagań 1.1 Użytkownik ma mieć możliwość definiowania typów plików zewnętrznych 1.2 Każdy zdefiniowany przez użytkownika typ pliku zewnętrznego musi mieć związane z nim oprogramowanie, które może zostać użyte do edycji plików tego typu. 1.3 Każdy plik zewnętrzny będzie reprezentowany w systemie przez ikonę. 1.4 Użytkownik ma mieć możliwość tworzenia i przypisywania ikon do typów plików zewnętrznych. 1.5 W wyniku kliknięcia myszą na ikonie reprezentującej plik zewnętrzny oprogramowanie związane z typem tego pliku ma zostać użyte do prezentacji zawartości tego pliku.

9 POZYSKIWANIE WYMAGAŃ

10 Pozyskiwanie wymagań Celem fazy pozyskiwania wymagań jest zebranie wymagań klienta wobec tworzonego systemu. Zbieranie wymagań to proces w którym klient łącznie z przedstawicielami producenta systemu konstruuje zbiór wymagań wobec systemu zgodnie z postawionymi celami i przyjętym zakresem. Zebrane wymagania dokumentowane są w Specyfikacji Wymagań Systemowych SWS (ang. SRS System Requirements Specification).

11 Inżynieria wymagań Inżynieria wymagań (ang. Requirements engineering) to całość działań związanych z pozyskiwaniem, reprezentowaniem, analizą i zarządzaniem wymaganiami. Etap zbierania wymagań jest traktowany jako jeden z najtrudniejszych w całym procesie produkcji oprogramowania. Osiągnięcie całkowicie poprawnej i pełnej specyfikacji wymagań jest niezwykle trudne ze względu na ciągłą ewolucję każdego systemu informatycznego.

12 Trzy metody pozyskiwania wymagań 1. Wywiady 2. Studia istniejących systemów 3. Prototypowanie

13 1. Wywiady Mają być przygotowane w postaci listy pytań i podzielone na odrębne zagadnienia. Mają umożliwić użytkownikowi zrozumienie konsekwencji wyborów i ich wpływ na ostateczną postać systemu Mają doprowadzić do szerokiej zgody i akceptacji projektu.

14 2. Studia istniejących systemów Są rozpatrywane w sytuacji gdy nowe oprogramowanie zastępuje stare. Mają ustalić wszystkie dobre i złe strony starego oprogramowania. Mają ustalić wymagania wobec nowego systemu, które zwykle związane są z usunięciem złych stron starego systemu, zachowaniem dobrych strony starego systemu, dodaniem nowych możliwości nieobecnych w starym systemie.

15 3. Prototypowanie Zbudowanie prototypu systemu działającego w mniejszej skali z uproszczonymi interfejsami. Na podstawie prototypu zebranie listy wymagań zwykle dotyczących: rozwinięcia funkcjonalności, poprawienia efektywności (np. szybszej pracy systemu), zmian w interfejsie (np. poprawy ergonomii). Budowa prototypu jest najbardziej kosztownym sposobem zbierania/uściślania wymagań.

16 Rodzaje wymagań Trzy podstawowe rodzaje wymagań: Wymagania funkcjonalne opisują one funkcje (czynności, operacje), które mają być wykonywane przez system, dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem. Wymagania niefunkcjonalne opisują ograniczenia (sprzętowe, prawne), przy zachowaniu których system ma realizować swoje funkcje. Wymagania przejściowe opisują ograniczenia o określonym czasie występowania, np. związane z migracją ze starego systemu do nowego.

17 Ważność fazy pozyskiwania wymagań Zbieranie wymagań jest fazą w której niezbędna jest najbardziej staranna weryfikacja i walidacja. Rozwijanie aplikacji w oparciu o niepoprawne wymagania może w skrajnym przypadku doprowadzić do wytworzenia nieodpowiedniego lub niepotrzebnego oprogramowania! Koszt naprawy błędów w specyfikacji wymagań rośnie zgodnie z zasadą 1:10, tzn. naprawa błędu specyfikacji wymagań kosztuje: 10 razy więcej na etapie projektowania, 100 razy więcej na etapie kodowania, 1000 razy więcej na etapie użytkowania i konserwacji niż na etapie specyfikacji.

18 Kto? Ustalenie interesariuszy projektu Zarządzający (cele biznesowe) Kontroler finansowy (koszty) Kierownik IT (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) Użytkownicy końcowi (wymagania funkcjonalne) Kierownik marketingu (cechy marketingowe) Kierownik ochrony (bezpieczeństwo) Dobrą praktyką jest ograniczanie liczby interesariuszy biorących udział w bezpośrednim opracowywaniu listy (definicji) wymagań (np. do kierowników działów, brygadzistów itp.). Jednak nie zwalnia to z obowiązku przeprowadzenia wywiadu na bezpośrednich stanowiskach pracy użytkowników.

19 Kto? Ustalenie interesariuszy Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Z każdą rolą jest związany określony punkt widzenia. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Punkty widzenia różnych interesariuszy są różne. Wszystkie punkty widzenia interesariuszy są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać przeanalizowane. Pojawiające się konflikty powinny zostać rozstrzygnięte.

20 Kto? Ustalenie klienta Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klient powinien należeć do interesariuszy projektu. W przeciwnym przypadku nie jest on zainteresowany wprowadzeniem systemu, a wtedy szanse zrealizowania projektu są minimalne. W organizacji klienta musi być wyznaczona osoba (kierownik projektu) odpowiedzialna za realizację projektu i reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi interesariuszami, aby zapewnić ich współpracę w fazie formułowania wymagań. W przypadku klienta szerokiego (produktu przeznaczonego dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących interesariuszy (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania.

21 Zrozumienie

22 Każdy słyszy to, co chce usłyszeć

23 Co? Cztery etapy pozyskiwania wymagań 1. Uświadomienie sobie przez interesariuszy ich potrzeb. 2. Sformułowanie potrzeb. 3. Transformowanie potrzeb na wymagania względem systemu. 4. Zdobycie uzupełniających informacji potrzebnych do zrozumienia wymagań.

24 1. Uświadamianie potrzeb Interesariusz może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami (fatalna sytuacja!). Interesariusz może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Interesariusz prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. W przypadku, gdy Interesariusz jest urządzeniem lub systemem, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji, do której trzeba dotrzeć.

25 2. Formułowanie potrzeb Interesariusz może mieć kłopoty z formułowaniem jasnych wypowiedzi. Interesariusz może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Interesariusz może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać (fatalnie!).

26 3. Zamiana potrzeb na wymagania Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Wymagania mogą być funkcjonalne, niefunkcjonalne i przejściowe. Istnieje konieczność klasyfikacji wymagań. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań.

27 4. Uzyskanie informacji potrzebnych do zrozumienia wymagań Informacje mogą być przechowywane w głowach pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi (bierny opór). Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być niekompletne. Informacje mogą być sprzeczne. Informacje mogą być mylące.

28 Trudność fazy pozyskiwania wymagań (1) Klient z reguły nie wie dokładnie w jaki sposób osiągnąć założone cele. Cele klienta mogą być osiągnięte na wiele sposobów. Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne. Różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach.

29 Trudność fazy pozyskiwania wymagań (2) Zleceniodawcy, sponsorzy i użytkownicy to często inne osoby. Głos zleceniodawców może być w tej fazie decydujący, chociaż nie zawsze potrafią oni właściwie przewidzieć potrzeby przyszłych użytkowników. W większości organizacji związanych z produkcją i eksploatacją oprogramowania jakość procesów inżynierii wymagań jest bardzo niska. Znaczenie tej fazy jest umniejszane, bardzo szybko przechodzi się do faz związanych bezpośrednio z produkcją (projektowanie, implementacja)

30 Zagrożenia w procesie pozyskiwania wymagań Wymagania muszą być zbierane w procesie iteracyjnym aż do uzyskania pewności, że pozyskana lista wymagań jest kompletna i poprawnie sformułowana. W wielu sytuacjach proces ten jest przerywany (np. z powodu kosztów, upływających terminów) w wyniku czego specyfikacja wymagań nie jest wystarczająco precyzyjna.

31 Zagrożenia w procesie pozyskiwania wymagań Przyczyny uzyskania specyfikacji wymagań nie w pełni kompletnej: Brak przeznaczenia wystarczających zasobów na realizację tego procesu. Pozyskane wymagania wydają się pozornie prawdziwe, lecz nie przeprowadzono dostatecznej ich analizy oraz ich kompletności i poprawności. Wykonano jedynie jedną iterację, a zespół zbierający wymagania nie jest wystarczający świadomy tego, że ponowny kontakt z klientem może wnieść nowe informacje co do ostatecznej postaci systemu.

Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

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

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

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

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

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

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

Etapy życia oprogramowania

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

Bardziej szczegółowo

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

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

Inżynieria oprogramowania II

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

Bardziej szczegółowo

Cykle życia systemu informatycznego

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

Bardziej szczegółowo

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

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

Opis metodyki i procesu produkcji oprogramowania

Opis metodyki i procesu produkcji oprogramowania Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie

Bardziej szczegółowo

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

Pryncypia architektury korporacyjnej

Pryncypia architektury korporacyjnej Pryncypia architektury korporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl Plan prezentacji Czym

Bardziej szczegółowo

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

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

Gry społecznościowe. wykład 0. Joanna Kołodziejczyk. 24 lutego Joanna Kołodziejczyk Gry społecznościowe 24 lutego / 11

Gry społecznościowe. wykład 0. Joanna Kołodziejczyk. 24 lutego Joanna Kołodziejczyk Gry społecznościowe 24 lutego / 11 Gry społecznościowe wykład 0 Joanna Kołodziejczyk 24 lutego 2017 Joanna Kołodziejczyk Gry społecznościowe 24 lutego 2017 1 / 11 Program przedmiotu Dwie formy zajęć: 1 Wykład studia stacjonarne (15h) 2

Bardziej szczegółowo

UPEDU: Rozpoznanie wymagań (ang. requirements discipline)

UPEDU: 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ółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie

Bardziej szczegółowo

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

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

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

Faza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja

Faza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja Faza strategiczna określenie wymagań specyfikowanie projektowanie kodowanie implementacja testowanie produkt konserwacja Faza strategiczna Analiza Synteza Dokumentacja Instalacja Faza strategiczna (ang.

Bardziej szczegółowo

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie do systemów informacyjnych Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj

Bardziej szczegółowo

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka Warszawa dnia 25 lutego 2013 r. Szanowni Państwo,, z siedzibą w Warszawie przy ul. Wolność 3A, zwraca się z prośbą o przedstawienie oferty cenowej na usługę analizy przedwdrożeniowej i wdrożenia dla aplikacji

Bardziej szczegółowo

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

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

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy dedykowanymi zasobami (ang. agile testers) Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań

Inżynieria Programowania Inżynieria wymagań Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 11 marca 2017 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu

Bardziej szczegółowo

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

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

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

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

Bardziej szczegółowo

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne:

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne: FAZA STRATEGICZNA Faza strategiczna jest wykonywana zanim podejmowana jest decyzja o realizacji przedsięwzięcia. Jej zadaniem jest określenie celów tworzonego systemu oraz wymagań odnośnie szczegółów jego

Bardziej szczegółowo

Wykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz

Wykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz Wykład 8 Testowanie w JEE 5.0 (1) Autor: 1. Rola testowania w tworzeniu oprogramowania Kluczową rolę w powstawaniu oprogramowania stanowi proces usuwania błędów w kolejnych fazach rozwoju oprogramowania

Bardziej szczegółowo

Przedsięwzięcia Informatyczne w Zarządzaniu

Przedsięwzięcia Informatyczne w Zarządzaniu Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

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

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

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

WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko

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

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki: Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

GoBiz System platforma współpracy marektingowej

GoBiz System platforma współpracy marektingowej GoBiz System platforma współpracy marektingowej Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel platformy... 2 3. Główni odbiorcy systemu... 2 4. Przedmiot zamówienia...

Bardziej szczegółowo

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI ZARZĄDZANIE I INŻYNIERIA PRODUKCJI STUDIA PIERWSZEGO STOPNIA PROFIL OGÓLNOAKADEMICKI Załącznik nr 2 Odniesienie efektów kierunkowych do efektów obszarowych i odwrotnie Załącznik nr 2a - Tabela odniesienia

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

Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami. dr inż. Agata Klaus-Rosińska

Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami. dr inż. Agata Klaus-Rosińska Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania konkretnego,

Bardziej szczegółowo

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

1. 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ółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

System epon Dokumentacja użytkownika

System epon Dokumentacja użytkownika System epon Dokumentacja użytkownika Prawa autorskie tego opracowania należą do MakoLab S.A. Dokument ten, jako całość, ani żadna jego część, nie może być reprodukowana lub rozpowszechniana w jakiejkolwiek

Bardziej szczegółowo

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank. Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności

Bardziej szczegółowo

Inżynieria Oprogramowania w Praktyce

Inżynieria Oprogramowania w Praktyce Inżynieria Oprogramowania w Praktyce Ogólna prezentacja kierunku Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego. www.aict.pjwstk.edu.pl 1 Kogo chcemy

Bardziej szczegółowo

Efekty kształcenia. Tabela efektów kształcenia

Efekty kształcenia. Tabela efektów kształcenia Efekty kształcenia Tabela efektów kształcenia W opisie efektów kierunkowych uwzględniono wszystkie efekty kształcenia występujące w obszarze kształcenia w zakresie nauk technicznych. Objaśnienie oznaczeń:

Bardziej szczegółowo

Miary funkcjonalne i co można z nimi zrobić fakty i mity. Warszawa, 7-8 czerwca 2017

Miary funkcjonalne i co można z nimi zrobić fakty i mity. Warszawa, 7-8 czerwca 2017 Miary funkcjonalne i co można z nimi zrobić fakty i mity Warszawa, 7-8 czerwca 2017 300 D&C w swojej działalności od lat promuje miary funkcjonalne wymiarujemy i szacujemy szkolimy: metody wymiarowania,

Bardziej szczegółowo

Jak kupować usługi full service? Dialog Branżowy Reklamodawca-Agencja

Jak kupować usługi full service? Dialog Branżowy Reklamodawca-Agencja Przed przejściem do punktów Agendy zdefiniowano usługi FULL SERVICE w reklamie. Przyjęto następującą definicję na potrzeby pracy: FULL SERVICE dotyczy zakresu prac Reklamodawcy oraz takich kompetencji

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

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

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

RUP. Rational Unified Process

RUP. 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ółowo

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować

Bardziej szczegółowo

Jakość w procesie wytwarzania oprogramowania

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

Bardziej szczegółowo

Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni

Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Tabela odniesień efektów kierunkowych do efektów obszarowych (tabele odniesień efektów kształcenia)

Tabela odniesień efektów kierunkowych do efektów obszarowych (tabele odniesień efektów kształcenia) Załącznik nr 7 do uchwały nr 514 Senatu Uniwersytetu Zielonogórskiego z dnia 25 kwietnia 2012 r. w sprawie określenia efektów kształcenia dla kierunków studiów pierwszego i drugiego stopnia prowadzonych

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

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

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

Bardziej szczegółowo

Faza analizy (modelowania) Faza projektowania

Faza analizy (modelowania) Faza projektowania Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań

Bardziej szczegółowo

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

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura

Bardziej szczegółowo

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

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

Bardziej szczegółowo

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny. "Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny". CZYNNIKI PROJEKTU Cel (zakres) projektu: wyznacza ramy przedsięwzięcia, a tym samym zadania

Bardziej szczegółowo

Zarządzanie usługami IT

Zarządzanie usługami IT Zarządzanie usługami IT Koncepcja usługowej organizacji IT oraz cykl życia usługi IT dr Remigiusz Orzechowski Instytut Zarządzania Wartością Kolegium Nauk o Przedsiębiorstwie Szkoła Główna Handlowa w Warszawie

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

KARTA PRZEDMIOTU. Systemy czasu rzeczywistego: D1_9

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

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Efekt kształcenia. Wiedza

Efekt kształcenia. Wiedza Efekty dla studiów drugiego stopnia profil ogólnoakademicki na kierunku Informatyka na specjalności Przetwarzanie i analiza danych, na Wydziale Matematyki i Nauk Informacyjnych, gdzie: * Odniesienie oznacza

Bardziej szczegółowo

Zarządzanie projektami. Wykład 2 dr inż. Agata Klaus-Rosińska

Zarządzanie projektami. Wykład 2 dr inż. Agata Klaus-Rosińska Zarządzanie projektami Wykład 2 dr inż. Agata Klaus-Rosińska 1 Etapy/fazy zarządzania projektem Rozpoczęcie (uruchomienie) projektu Planowanie projektu Realizacja projektu Zamknięcie projektu Rozpoczęcie

Bardziej szczegółowo

Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska. Miedzeszyn, wrzesień 2010

Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska. Miedzeszyn, wrzesień 2010 Jak nie stracić efektów synergii usługi systemów krajowych i globalnych Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska Miedzeszyn, wrzesień 2010 Bartosz Górczyński Prezes Zarządu CTPartners

Bardziej szczegółowo

Zagadnienia. Inżynieria Oprogramowania

Zagadnienia. Inżynieria Oprogramowania Zagadnienia Co to jest extreme Programming (XP) Czym charakteryzują się tzw. lekkie metodyki zarządzania procesem produkcji oprogramowania Reguły i praktyki XP Dlaczego i kiedy można a w jakich przypadkach

Bardziej szczegółowo

ZASADY TWORZENIA OPROGRAMOWANIA

ZASADY TWORZENIA OPROGRAMOWANIA ZASADY TWORZENIA OPROGRAMOWANIA 1. Tylko złożone oprogramowanie wymaga inżynierii (cykl życia składający się z modelowania i testowania oraz sprzężenia zwrotnego prosty problem, zajęcia z programowania)

Bardziej szczegółowo

<Nazwa firmy> <Nazwa projektu> 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

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

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