Obiekty graniczne pomiędzy technikami inżynierii oprogramowania a technikami użyteczności i Kansei

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

Download "Obiekty graniczne pomiędzy technikami inżynierii oprogramowania a technikami użyteczności i Kansei"

Transkrypt

1 This paper should be cited as: Bobkowska, A., Kaźmierowski, R., & Wójcik, A. (2008). Obiekty graniczne pomiędzy technikami inżynierii oprogramowania a technikami użyteczności i Kansei. Proceedings of the Conference: Interfejs użytkownika - Kansei w praktyce. Warsaw: Wydawnictwo PJWSTK. Obiekty graniczne pomiędzy technikami inżynierii oprogramowania a technikami użyteczności i Kansei ANNA BOBKOWSKA, RAFAŁ KAŹMIEROWSKI, AGNIESZKA WÓJCIK Politechnika Gdańska, ul. Narutowicza 11/12, Gdańsk Idea obiektów granicznych została spopularyzowana przez badania w nurcie integracji dyscyplin inżynierii oprogramowania i użyteczności (ang. Bridging the SE & HCI Communities) [5]. Obiekt graniczny jest to pewna abstrakcja wspólnej przestrzeni pojęć, podstawowych założeń i wspólnej wiedzy, wspólnych produktów, zadań i odpowiedzialności, które mogą służyć do integracji i koordynacji działań osób lub zespołów posiadających różne specjalizacje. Pierwsza część referatu ma na celu podsumowanie zagadnień integracji inżynierii oprogramowania i użyteczności. W sekcji drugiej zawarto krótkie przypomnienie badań międzynarodowych oraz badań ankietowych przeprowadzonych w Polsce. W sekcji trzeciej podjęto próbę usystematyzowania korzyści z wymiany wiedzy pomiędzy dyscyplinami w następujących obszarach: wykorzystanie technik inżynierii oprogramowania w użyteczności, wykorzystanie technik użyteczności w inżynierii oprogramowania, integracja technik z obu grup w projekcie informatycznym. Wymiana wiedzy pomiędzy dyscyplinami przynosi korzyści obu dyscyplinom. Zastosowanie technik inżynierii oprogramowania umożliwia poprawę precyzji opisu modeli i procesów stosowanych w użyteczności, a zastosowanie technik użyteczności daje możliwość poprawy jakości użytkowej narzędzi stosowanych w inżynierii oprogramowania (narzędzi CASE). Druga część referatu ma na celu prezentację praktycznego rozwiązania integracyjnego w odpowiedzi na potrzebę spojenia technik z obu grup w jeden proces bez znaczącego przyrostu czasu realizacji. Wybrano podejście bazujące na konfiguracji procesu i przedstawiono propozycję połączenia inżynierii Kansei oraz wybranej techniki użyteczności z IBM RUP (Rational Unified Process) [7]. W tym celu, w kolejnych sekcjach, techniki podlegające połączeniu zostały opisane zgodnie ze standardem SPEM (Software and Systems Process Engineering Metamodel) [11], który jest stosowany w opisie procesu RUP oraz omówione zostały obiekty graniczne łączące te techniki z RUP. Strona 1

2 Zagadnienia integracji inżynierii oprogramowania i użyteczności Nurt integracji dyscyplin inżynierii oprogramowania i użyteczności (ang. Bridging the SE & HCI Communities) [5] powstał w odpowiedzi na problemy związane z rozdzieleniem tych dwóch dyscyplin spowodowane ich niezależnym rozwojem, trudnościami w integracji wyników osiągniętych przez osobne grupy badaczy oraz problemami we współpracy na poziomie projektu informatycznego, którego realizacja powinna uwzględniać zarówno aspekty techniczne powiązane z inżynierią oprogramowania jak i aspekty związane z zapewnieniem jakości użytkowej. Jakość techniczna oprogramowania i jakość użytkowa są ze sobą ściśle powiązane, a odpowiednie skoordynowanie zadań z obu dyscyplin w procesie wytwarzania oprogramowania wpływa na efektywność prowadzenia projektu. Sposobem na rozwiązanie tych problemów było wprowadzenie obiektów granicznych. Obiekt graniczny to pewna abstrakcja wspólnej przestrzeni pojęć, podstawowych założeń i wspólnej wiedzy, wspólnych produktów, zadań i odpowiedzialności, które mogą służyć do integracji i koordynacji działań osób lub zespołów posiadających różne specjalizacje. Obiekty graniczne mogą powstać na poziomie dyscyplin albo na poziomie projektów w konkretnych firmach, przy czym obiekty graniczne na poziomie dyscyplin ułatwiają zastosowanie w projektach informatycznych. W praktyce występują trzy rodzaje obiektów granicznych: ludzie, którzy posiadają umiejętności zrozumienia perspektywy innych, wykorzystania wykonywanych przez innych produktów, utworzenia płaszczyzny porozumienia oraz wspólnej przestrzeni działania, np. kierownicy projektów, osoby przeszkolone w zakresie obu dyscyplin; procesy, które definiują, jakie zadania, kiedy, jak i przez kogo powinny być wykonywane, np. zintegrowany proces wytwarzania oprogramowania, proces komunikacji i podejmowania decyzji; produkty, które zawierają opis sposobu wykonywania zadań, szablony i specyfikacje projektowe, np. specyfikacja wymagań, dokument planu projektu, szablon opisu kontekstu użycia, prototypy interfejsów użytkownika, raport z przeglądu. Z badań ankietowych badających sytuację na styku inżynierii oprogramowania i użyteczności w Polsce [1] wynika, że w firmach informatycznych stopień zaawansowania i formalności metod inżynierii oprogramowania jest większy niż metod użyteczności. Częściej stosowane są te techniki użyteczności, które są bardziej zbliżone do inżynierii oprogramowania, np. prototypowanie, wywiady, przewodniki styku, scenariusze użycia, planowanie. Wśród czynników wpływających na wybór technik użyteczności najczęściej wymieniane były łatwość wprowadzenia i analiza przewidywanych korzyści. Jako model integracji najczęściej występuje włączenie poszczególnych technik użyteczności do procesu wytwarzania zdefiniowanego według zasad z inżynierii oprogramowania. W Polsce obecnie występuje tendencja wprowadzania coraz większej liczby technik użyteczności. Podczas wprowadzania technik użyteczności bardziej odległych od terminologii i metod inżynierii oprogramowania pojawiają się problemy opisywane w literaturze międzynarodowej i wówczas stosowane są obiekty graniczne pochodzące ze wszystkich trzech grup. Wśród Strona 2

3 istotnych tematów badań na pograniczu inżynierii oprogramowania i użyteczności znalazł się problem spojenia technik z obu grup w jeden proces bez znaczącego przyrostu czasu realizacji. Z przedstawionego podsumowania powiązanych z tematem rezultatów badania ankietowego wynika, że występuje potrzeba badań w zakresie obiektów granicznych. Dodatkowo, słusznym podejściem do integracji procesu wydaje się opis technik użyteczności zgodnie z zasadami opisu procesu w inżynierii oprogramowania, gdyż w ten sposób ułatwione jest włączenie ich do procesu wytwarzania. Korzyści z wymiany wiedzy pomiędzy dyscypliną inżynierii oprogramowania a dyscypliną użyteczności Większość badań z nurtu integracji użyteczności i inżynierii oprogramowania dotyczy zastosowania technik z obu grup w projekcie informatycznym. Jednak wymiana wiedzy pomiędzy tymi dyscyplinami może dostarczać korzyści także tym dyscyplinom. Osiągnięcia jednej dyscypliny są przydatne dla drugiej ze względu na koncentrację na innych aspektach lub ze względu na to, że w jednej dyscyplinie występowały bardziej skomplikowane problemy i stąd wypracowane zostały bardziej zaawansowane rozwiązania niż w drugiej. W dalszej części tej sekcji podsumowano badania w następujących trzech obszarach: wykorzystanie technik inżynierii oprogramowania w użyteczności, wykorzystanie technik użyteczności w inżynierii oprogramowania, integracja technik z obu grup w projekcie informatycznym. Podstawą wykorzystania technik inżynierii oprogramowania w użyteczności jest obserwacja, że w inżynierii oprogramowania jest większa złożoność problemu, z którą musi sobie radzić wykonawca oprogramowania oraz z tego, że wymagany jest większy poziom precyzji. Można więc zastosować wypracowane techniki do poprawy precyzji opisu technik użyteczności. Jednym z zastosowań jest zastosowanie meta modeli do opisu modeli zadaniowych [2], dzięki któremu uzyskano poprawę dokładności opisu i większą zwięzłość opisu. Dzięki temu łatwiejsze było zrozumienie i porównywanie modeli. Zaprezentowana w drugiej części tego referatu propozycja zastosowania metody opisu procesu wypracowanej w inżynierii oprogramowania (SPEM) do opisu procesu wykonywania zadań użyteczności i Kansei umożliwia dokładniejszy opis, ułatwia integrację z procesem inżynierii oprogramowania oraz daje szereg innych korzyści wynikających z konfiguracji procesu wytwarzania. Inżynieria oprogramowania posiada także bardziej zaawansowane techniki planowania projektu w porównaniu z planowaniem użyteczności, uwzględniając priorytety, cykle życia, harmonogramy itp. Podsumowując, dyscyplina użyteczności może wykorzystać z inżynierii oprogramowania wiedzę na temat opisu modeli, procesów oraz projektu. Strona 3

4 Podstawą wykorzystania technik użyteczności w inżynierii oprogramowania jest obserwacja, że narzędzia CASE (ang. Computer Aided Software Engineering) są także oprogramowaniem, a jakość użytkowa tych narzędzi wpływa na efektywność i satysfakcję pracy informatyków. Niestety większość narzędzi CASE jest wytwarzana głównie z myślą o dostarczeniu określonej funkcjonalności. W celu oceny lub poprawy jakości użytkowej narzędzi CASE można zastosować techniki użyteczności. Badania oceny jakości użytkowej pokazały, że różnica w produktywności wykonywania tych samych zadań modelowania z zastosowaniem różnych narzędzi UML może dochodzić do 40% [3]. Za pomocą badań dostosowania narzędzi UML do różnych profili użytkowników można pokazać, że są znaczne różnice we wsparciu narzędzi UML dla poszczególnych ról związanych z wytwarzaniem oprogramowania [4]. Tradycyjne listy heurystyk użyteczności mogą być zastosowane (po drobnym dostosowaniu) do badania ogólnych cech jakości użytkowej narzędzi UML [13]. Z punktu widzenia firmy stosującej narzędzia UML, ocena ogólnej jakości użytkowej oraz dopasowania do konkretnych profili pracowników może mieć wpływ na wybór narzędzia. Natomiast firmy wytwarzające narzędzia UML mogą wykorzystywać te techniki do poprawy użyteczności swoich produktów. Przykładem narzędzia UML, którego producent zainteresował się aspektami użyteczności, jest Visual Paradigm [15]. Skutkiem tego jest większa możliwość dostosowania wyglądu narzędzia oraz diagramów do preferencji użytkownika; unikalny system uchwytów wokół elementów diagramu, który przyspiesza modelowanie powiązanych elementów oraz rozpoznawanie gestów wykonywanych myszką na podstawie których wstawiane są odpowiednie symbole. We wspomnianych badaniach produktywności Visual Paradigm zdobył najlepsze wyniki. Podsumowując, inżynieria oprogramowania może wykorzystać wiedzę z zakresu użyteczności do poprawy jakości użytkowej narzędzi CASE. Integracja technik inżynierii oprogramowania i użyteczności w projekcie ma służyć zwiększeniu efektywności prowadzenia prac projektowych dzięki usunięciu nadmiarowości wykonywania podobnych prac przez zespoły z inną specjalizacją oraz poprawie komunikacji pomiędzy tymi zespołami. W ramach nurtu integracji inżynierii oprogramowania i użyteczności zaproponowano kilka sposobów integracji, np.: integrację użyteczności i inżynierii wymagań [8], w którym wyodrębniono decyzje oraz opis na poziomie zadań, dziedziny, interakcji oraz systemu; metodę włączania technik użyteczności do procesu wytwarzania oprogramowania [6] z dopasowaniem terminologii do słownictwa używanego w inżynierii oprogramowania; podejście do koordynacji działań z obu dyscyplin z przekazywaniem odpowiednich specyfikacji [9]; próbę rozszerzenia RUP (Rational Unified Process) o opis ról, zadań i artefaktów związanych z użytecznością [12]; włączenie do RUP opisu wytwarzania ukierunkowanego na użytkownika (ang. user centered design) i inżynierii użyteczności, jednak mają one status jedynie koncepcji i zaleceń. Strona 4

5 W dalszej części tego referatu przyjęto podejście polegające na integracji z RUP. Jednak w odróżnieniu od podejścia opisanego w [12] polegającego na dopisaniu elementów użyteczności na niskim poziomie abstrakcji, w zaproponowanym podejściu wyróżniane są osobne dyscypliny Kansei i użyteczności oraz wskazywane są w jawny sposób obiekty graniczne, które służą ich połączeniu. Takie podejście jest bardziej elastyczne i zgodne z ideą konfigurowalności procesu. W odróżnieniu od ostatniego podejścia, zastosowane zostanie modelowanie zadań użyteczności zgodnie ze SPEM. Opis procesu wytwarzania zgodnie ze standardem SPEM Software and Systems Process Engineering Meta model (SPEM) [11] jest standardem służącym do opisu procesu wytwarzania oprogramowania. SPEM wyróżnia następujące poziomy opisu: zawartość metod (ang. method content), która zawiera definicję zadań, produktów oraz ról osób odpowiedzialnych za ich wykonanie w wymiarze statycznym; proces (ang. process), który wykorzystuje zdefiniowane zadania, produkty i role, łącząc je w większe fragmenty procesu realizowane podczas wytwarzania określonych typów systemów (wymiar dynamiczny). Zawartość poszczególnych metod może być wykorzystana w różnych procesach lub w wielu miejscach tego samego procesu. Opis procesu wytwarzania systematyzuje w firmie wiedzę na temat procesów wytwórczych, ułatwia konfigurację procesu i powoduje poprawę precyzji jego opisu. Dzięki dołączonym pomocom (ang. guidance), do których zaliczyć można szablony, listy kontrolne, opis dobrych praktyk, podręczniki, artykuły o powiązanej tematyce, procedury itp., stanowi pomoc podczas realizacji projektu oraz wprowadzenie dla nowych pracowników. Precyzyjny opis procesu ułatwia planowanie konkretnych projektów danego typu poprzez udostępnienie szablonu ich realizacji. SPEM dostarcza notacji graficznej do modelowania zawartości metod oraz procesu. Najważniejsze symbole zostały pokazane na rysunku 1. Dla zawartości metod stosowane są głównie diagramy pokazujące powiązania ról z zadaniami i produktami, natomiast dla procesu diagramy aktywności. Pierwszym procesem, który został opisany zgodnie ze SPEM, jest IBM RUP. Strona 5

6 Rys. 1. Symbole stosowane podczas opisu zawartości metod i procesu, źródło: [11] Zaprezentowana w tym referacie próba opisu technik Kansei oraz użyteczności zgodnie ze SPEM ma na celu zwiększenie precyzji opisu tych technik, łatwiejszą integrację tych technik z technikami inżynierii oprogramowania zawartymi w RUP (co wynika z zastosowania wspólnego języka opisu) oraz umożliwienie odniesienia szeregu korzyści, które są osiągane w inżynierii oprogramowania na skutek precyzyjnego opisu procesu wytwarzania. Opis inżynierii Kansei według SPEM Na rysunku 2 pokazano czynności występujące w ramach inżynierii Kansei [10] opisywanej tu jako dyscyplina Kansei, a w tablicy 1 przedstawiono opis tych czynności. Strona 6

7 Rys. 2. Czynności występujące podczas realizacji procesu Kansei. Strona 7

8 W skład czynności wchodzą zadania, a w opisie zadań występują kroki. Zadania wykonywane na etapie określania przestrzeni właściwości przedstawiono na rysunku 3. Rys. 3. Zadania związane z określaniem przestrzeni właściwości. Nazwa czynności Określenie dziedziny (zakresu i celu) Określenie przestrzeni semantycznej Opis czynności Definiowanie dziedziny produktu, czyli określenie zakresu produktu i jego celu, określenie środowiska docelowego produktu (produkty o podobnej cenie lub jakości, grupa wiekowa przyszłych użytkowników) oraz wyznaczenie najważniejszych cech produktu. Określenie kolekcji słów opisujących właściwości produktu w celu wyodrębnienia słów najlepiej opisujących szukane cechy produktu. Przestrzeń określeń składa się z etapów: 1. wyznaczenia zbioru słów opisujących typ wybranego produktu i jego dziedzinę; 2. wskazaniu słów, które mają największy wpływ na umysł użytkownika; 3. wskazanie słów Kansei, które mają największe znaczenie strategiczne dla tworzonego produktu. Strona 8

9 Określenie przestrzeni właściwości Określenie zbioru określeń technicznych lub inżynieryjnych produktu, które można wyrazić w wartościach liczbowych np. średnica, waga, czas (zob. rys. 3.) W ramach określania przestrzeni właściwości wyróżnione są następujące zadania: 1. Określenie cech produktu wyszukiwane są słowa określające cechy produktu z różnych źródeł np. z technicznych specyfikacji produktu czy opinii ekspertów; 2. Selekcja najistotniejszych cech produktu; 3. Wskazanie reprezentacji produktu tworzenie modeli produktów posiadających określone cechy. Synteza modelu Połączenie przestrzeni semantycznej z przestrzenią właściwości. Pierwszym krokiem jest ocena produktu przez użytkowników według skali semantycznej powiązanej ze słowami Kansei. W ramach analizy wyników następuje powiązanie słów Kansei z przestrzeni semantycznej z określonymi właściwościami produktów z zastosowaniem metod statystycznych. Wynikiem syntezy obu zbiorów jest wskazanie kluczowych cech wytwarzanego produktu. Walidacja modelu Przewartościowanie słów Kansei i wyznaczenie czynników różnicujących produkty z udziałem zamawiającego produkt, którego zadaniem jest wskazanie kluczowych pojęć określających cechy produktu zgodne z jego wizją produktu. Tworzenie modelu Tworzenie modeli matematycznych z uwzględnieniem wyników z poprzednich etapów. Tablica 1: Opis czynności występujących podczas realizacji procesu Kansei Do każdego zadania i kroku można dołączyć pomoce zawierające wskazówki, jak ma przebiegać ich wykonanie, listy kontrolne oraz informację o narzędziach, które można zastosować. W inżynierii Kansei można wyodrębnić następujące role: kierownik procesu Kansei zajmuje się planowaniem procesu Kansei oraz kontroluje ten proces i jego wyniki; analityk dziedziny w fazie rozpoczęcia jest on odpowiedzialny za przeprowadzenie wywiadów z zamawiającym oraz rozpoznanie jego wizji i potrzeb względem produktu. Przeprowadza on również analizę rynku, w czasie której wyszukuje produkty o podobnych właściwościach estetycznych oraz ekonomicznych i określa grupę odbiorców na podstawie wywiadów z klientem; Strona 9

10 decydent przedstawiciel zamawiającego, który akceptuje (lub nie akceptuje) wyniki integracji zbioru semantycznego ze zbiorem właściwości; może również wartościować słowa i tworzyć nowe na podstawie istniejących już zestawień; badacz jest odpowiedzialny za określenie zbiorów semantycznych i właściwości, przewartościowanie wyników obu zbiorów oraz za stworzenie ankiet dla ankietowanych. Tworzenie zbiorów słów Kansei odbywa się zazwyczaj metodami heurystycznymi np. burza mózgów, w której mogą brać udział osoby nie związane z projektem, udziałowcy i osoby z określonej grupy odbiorców; ankietowany osoba z określonej wcześniej przez analityka dziedziny grupy odbiorców, która bierze udział w ocenie produktu o określonych właściwościach względem słów Kansei pochodzących ze zbioru przestrzeni semantycznej. Rys. 4. Rola Decydent wraz z jej zadaniami i produktami, za które jest odpowiedzialna Przykładowy opis struktury odpowiedzialności dla roli decydent pokazano na rysunku 4. Wynika z niego, że decydent wskazuje kluczowe słowa Kansei na podstawie słów Kansei, a produktem wykonania tego zadania są słowa kluczowe. Opis oceny heurystycznej z dyscypliny użyteczności Ocena heurystyczna [14] jest jedną z technik zawartych w dyscyplinie użyteczności. Została on zaklasyfikowana jako czynność w notacji SPEM. Ocena heurystyczna jest formą oceny użyteczności, w czasie której specjaliści użyteczności oceniają różne elementy interfejsu użytkownika na podstawie zdefiniowanego wykazu heurystyk użyteczności. Na rysunku 5 pokazano strukturę zadań i produktów dla oceny heurystycznej, a w tablicach 2 i 3 zawarto opis produktów i zadań występujących na diagramie. Rolę analityka użyteczności pełnią eksperci z dziedziny interakcji pomiędzy człowiekiem a komputerem oraz specjaliści od czynników ludzkich. Strona 10

11 Rys. 5. Struktura zadań i produktów dla oceny heurystycznej Produkt System / Prototyp Opis Produkt, który zostanie poddany analizie użyteczności. Heurystyki Zbiór zasad i zaleceń użyteczności, np. heurystyki użyteczności J. Nielsena takie jak widoczność stanu systemu, estetyczna i minimalistyczna stylistyka. Lista problemów Raport z oceny heurystycznej Wynik indywidualnej pracy analityka w postaci listy wykrytych problemów pod względem heurystyk. Raport zawierający ocenę heurystyczną przedmiotu analizy, który powstaje w wyniku scalenia list problemów. Tablica 2: Opis produktów związanych z oceną heurystyczną Strona 11

12 Zadanie Wykrywanie problemów Scalanie wyników Opis Indywidualna praca analityka użyteczności polegająca na wyszukiwaniu defektów na podstawie heurystyk. Składa się z dwóch kroków: zapoznania się z systemem oraz szczegółowej kontroli, która może być powtarzana wiele razy (zob. rysunek 6) Produktem jest lista problemów. Scalanie wyników indywidualnej pracy kilku analityków użyteczności, analiza i tworzenie rankingu problemów. Produktem jest raport z oceny heurystycznej. Tablica 3: Opis zadań związanych z oceną heurystyczną Rys. 6. Wizualizacja kroków podczas wykrywania usterek Szczegółowe zasady i zalecenia użyteczności mogą być zawarte w pomocach. Przykładowymi pomocami istotnym dla oceny heurystycznej jest zalecenie aby w ocenie heurystycznej brało udział od trzech do pięciu analityków, lista heurystyk i szablony list problemów lub raportów. Strona 12

13 Obiekty graniczne W wyniku modelowania oceny heurystycznej i inżynierii Kansei (w osobnych dyscyplinach użyteczności i Kansei) powstał opis tych technik w języku SPEM zgodnym z językiem opisu RUP, ale dotychczas te techniki nie zostały jeszcze powiązane z elementami RUP. Integracja z RUP polega na utworzeniu odpowiednich obiektów granicznych, tzn. na pokazaniu jakie produkty są przekazywane, jakie zadania są wykonywane wspólnie, kto jest odpowiedzialny za wykonanie i koordynację tych zadań itp. Wyodrębnienie obiektów granicznych powinno być poprzedzone analizą nakładania się elementów z integrowanych procesów oraz potencjalnych miejsc styku. Obiekt graniczy może występować na poziomie dyscypliny, jako wiedza na temat nakładania się elementów procesu, potencjalnych miejsc styku oraz propozycji ich połączenia, albo na poziomie procesu projektowego wówczas reprezentuje konkretną konfigurację procesu. Dyscypliny użyteczności i Kansei są najściślej związane z projektowaniem interfejsów użytkownika. Projektowanie interfejsu użytkownika w RUP występuje jako zadanie w dyscyplinie RUP o nazwie analiza i projektowanie. Rolą odpowiedzialną za wykonanie tego zadania jest projektant interfejsu, a produktami są mapa nawigacji oraz prototypy ekranów. Powinny one być wykonywane z zastosowaniem zaleceń projektowania interfejsu użytkownika na podstawie specyfikacji wymagań oraz innych dokumentów pomocniczych, np. wizji systemu, przypadków użycia, wymagań udziałowców. W aspekcie zakresu systemu i dopasowania systemu do zadań wykonywanych przez użytkownika, dyscypliny użyteczności i Kansei powiązane są ze specyfikacją wymagań oraz wizją systemu z dyscypliny RUP o nazwie wymagania. Połączenie oceny heurystycznej z projektowaniem interfejsu użytkownika jest dość łatwe. Zadania te uzupełniają się, więc można je połączyć. Prototypy interfejsu użytkownika wykonane zgodnie z RUP mogą podlegać ocenie heurystycznej, a następnie wyniki tej oceny mogą być podstawą poprawy prototypów. Obiekt graniczny składa się z następujących elementów: przekazywane produkty: prototyp interfejsu użytkownika oraz raport z oceny heurystycznej; wspólne procesy: dyskusja wyników oceny, opis procesu przekazywania produktów; poziom osób: kierownik projektu, który jest koordynatorem działań projektantów interfejsu użytkownika i analityków użyteczności. Połączenie dyscypliny Kansei z RUP jest już nieco trudniejsze. Inżynieria Kansei jest bardziej skomplikowana, a dodatkowo występuje nakładanie się produktów i zadań z obu dyscyplin. W zakresie produktów określenie dziedziny (zakresu i celu) z inżynierii Kansei zawiera elementy opisywane w wizji systemu (RUP), a prototyp interfejsu użytkownika (RUP) nakłada się na wynik wskazania reprezentacji produktu z inżynierii Kansei. Strona 13

14 Nakładanie występuje również na poziomie zadań prowadzących do wykonania tych produktów.w tym przypadku jest możliwych kilka rozwiązań: wykonywanie prototypu interfejsu użytkownika (zgodnie z RUP), a następnie przekazanie go wraz ze specyfikacjami do udoskonalania poprzez techniki Kansei; zastąpienie projektowania interfejsu użytkownika (RUP) poprzez cały proces inżynierii Kansei w tym przypadku występuje problem integracji z zakresem funkcjonalności (część inżynierii oprogramowania), więc obiektami granicznymi z kategorii produktów są specyfikacje wymagań, wizja systemu i przypadki użycia. Podsumowanie Zaproponowane podejście do integracji technik użyteczności i Kansei z procesem inżynierii oprogramowania (RUP) zawiera modelowanie tych technik zgodnie ze standardem SPEM oraz jawny opis obiektów granicznych. Techniki są modelowane w ramach osobnych dyscyplin: dyscypliny inżynierii Kansei oraz dyscypliny inżynierii użyteczności. Modelowanie zwiększa precyzję i spójność opisu oraz ułatwia połączenie z RUP dzięki zastosowaniu wspólnego języka opisu. Wyodrębnienie obiektów granicznych powinno być poprzedzone analizą miejsc nakładania i potencjalnych miejsc styku. Analiza miejsc nakładania służy wyeliminowaniu nadmiarowości pracy i niespójności pomiędzy różnymi produktami opisującymi te same wymagania lub decyzje. Analiza potencjalnych miejsc styku pokazuje punkty integracji technik z różnych dyscyplin w jeden proces. Miejscami styku mogą być przekazywane produkty; fragmenty procesów, w których łączą się lub są wspólnie wykonywane zadania z kilku dyscyplin oraz przydział odpowiedzialności koordynujących poszczególnym rolom. Gdy występuje nakładanie się zawartości technik, obiekty graniczne na poziomie dyscypliny mogą zawierać kilka propozycji integracji. Obiekty graniczne na poziomie projektu odzwierciedlają konkretną konfigurację procesu. Literatura 1. A. Bobkowska, K. Grabiec; Integracja technik użyteczności i technik inżynierii oprogramowania w projekcie informatycznym, W: Interfejs użytkownika Kansei w praktyce ; A. Bobkowska, M. Kosidowska; Porównanie podejść do opisu kontekstu użycia z wykorzystaniem meta modeli, W: Interfejs użytkownika Kansei w praktyce ; A. Bobkowska, K. Reszke; Usability of UML modeling tools W: Software engineering: evolution and emerging technologies, seria: Frontiers in Artificial Intelligence and Applications, IOS Press; A. Bobkowska, M. Weihs; Verification of the Fit to User Profiles for UML Tools, W: Proceedings of 1st International IEEE Conference on Information Technology ; Bridging the SE & HCI Communities, hci.org/bridging/ (dostęp ) Strona 14

15 6. X. Ferre; Integration of usability techniques into the Software Development Process ; W: Proceedings of the workshop Bridging the Gaps Between Software Engineering and Human Computer Interaction at ICSE; IBM Rational Unified Process, 8. B. Paech, K. Kohler; Usability Engineering integrated with Requirements Engineering ; W: Proceedings of the workshop Bridging the Gaps Between Software Engineering and Human Computer Interaction at ICSE; P.S. Pyla, M.A. Perez Quinnones, J.D. Arthur, H.R. Hartson; Towards a Model based Framework for Integrating Usability and Software Engineering Life Cycles ; W: Proceedings of the workshop Closing the Gap: Software Engineering and Human Computer Interaction at INTERACT Conference; S. Schütte, J. Eklund; Product Development for Heart and Soul. An introduction to Kansei Engineering Methodology, Linköpings Universitet, Department for Human Systems Engineering, Sweden; Software and Systems Process Engineering Meta model (SPEM) pdf 12. K.S. Sousa, E. Furtado; UPi A Unified Process for Designing Multiple UIs ; W: Proceedings of the workshop Bridging the Gaps II: Bridging the Gaps Between Software Engineering and Human Computer Interaction at ICSE; M. Staszkiewicz; Metoda oceny użyteczności narzędzi UML, praca dyplomowa na wydziale ETI PG; Usability Net, (dostęp ) 15. Visual Paradigm for UML, paradigm.com (dostęp ) Strona 15

Konfiguracja modelowania w procesie wytwarzania oprogramowania

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

Bardziej szczegółowo

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

> Zagadnienie integracji technik użyteczności i technik inżynierii oprogramowania wynika

> Zagadnienie integracji technik użyteczności i technik inżynierii oprogramowania wynika This paper should be cited as: Bobkowska, A., & Grabiec, K. (2007). Integracja technik użyteczności i technik inżynierii oprogramowania w projekcie informatycznym. Proceedings of the Conference: Interfejs

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

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

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

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language) Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1 SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2

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

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

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

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

Bardziej szczegółowo

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

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

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

Należyta staranność w inżynierii wymagań i modelowaniu systemów. Anna Bobkowska Politechnika Gdańska

Należyta staranność w inżynierii wymagań i modelowaniu systemów. Anna Bobkowska Politechnika Gdańska Należyta staranność w inżynierii wymagań i modelowaniu systemów Anna Bobkowska Politechnika Gdańska 1. Wstęp Wypracowanie schematów postępowania podczas stwierdzania, czy została dołożona należyta staranność

Bardziej szczegółowo

Omówienie założeń procesu Design Thinking i przeprowadzenie wstępnego warsztatu. Mariusz Muraszko i Mateusz Ojdowski Logisfera Nova

Omówienie założeń procesu Design Thinking i przeprowadzenie wstępnego warsztatu. Mariusz Muraszko i Mateusz Ojdowski Logisfera Nova Dzień 1 PONIEDZIAŁEK 1.09.2014 8:00-10:00 Wprowadzenie do UX Otwarcie szkoły letniej wraz z wprowadzeniem do User Experience, przedstawienie struktury UX, narzędzi używanych przez specjalistów i dobrych

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

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

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

Inżynieria oprogramowania. Jan Magott Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE

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

HCI Human Computer Interaction

HCI Human Computer Interaction HCI Human Computer Interaction Bartosz Dzirba Gabriel Kujawski praca dyplomowa magisterska opiekun: prof. dr hab. Zbigniew Kotulski 1 Plan prezentacji HCI Co to jest? W jakim celu? Jak projektować? Etapy

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Analiza biznesowa a metody agile owe

Analiza biznesowa a metody agile owe Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Modelowanie obiektowe - Ćw. 3.

Modelowanie obiektowe - Ćw. 3. 1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Porównanie podejść do opisu kontekstu użycia z wykorzystaniem meta-modeli

Porównanie podejść do opisu kontekstu użycia z wykorzystaniem meta-modeli This paper should be cited as: Bobkowska, A., & Kosidowska, M. (2006). Porównanie podejść do opisu kontekstu użycia z wykorzystaniem meta-modeli. Unpublished paper presented at Interfejs użytkownika -

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

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017 Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy

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

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

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

Egzamin / zaliczenie na ocenę* WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli

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

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

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

WPROWADZENIE DO UML-a

WPROWADZENIE DO UML-a WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,

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

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

Analiza i projektowanie obiektowe w UML Kod przedmiotu

Analiza i projektowanie obiektowe w UML Kod przedmiotu Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,

Bardziej szczegółowo

DESIGN THINKING. Peter Drucker. Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale.

DESIGN THINKING. Peter Drucker. Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale. DESIGN THINKING Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale. Peter Drucker WSTĘP Zdajemy sobie sprawę, że każdą organizację tworzą ludzie, dlatego

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

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

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

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

Bardziej szczegółowo

Architektura oprogramowania w praktyce. Wydanie II.

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

Bardziej szczegółowo

Podstawy modelowania biznesowego w inżynierii oprogramowania

Podstawy modelowania biznesowego w inżynierii oprogramowania Podstawy modelowania biznesowego w inżynierii oprogramowania 1. Rola modelowania biznesowego w inżynierii oprogramowania 2. Przegląd notacji (BPMN, UML w zast. biznesowym) 3. Powiązania modeli biznesowych

Bardziej szczegółowo

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

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

Bardziej szczegółowo

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań Albert Ambroziewicz, Michał Śmiałek Politechnika Warszawska KKIO 0, SCR 0 27-29.09.200 Treść prezentacji Wprowadzenie powtarzalność rozwiązań w IO Koncepcja

Bardziej szczegółowo

Innowacyjne narzędzia do zarządzania kompetencjami i ich rozwoju

Innowacyjne narzędzia do zarządzania kompetencjami i ich rozwoju Innowacyjne narzędzia do zarządzania kompetencjami i ich rozwoju Od aspiracji... do realnych potrzeb naszych klientów Od aspiracji Przy planowaniu prac nad rozwojem autorskiej platformy MN Portal zapytaliśmy

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

ANALIZA EKONOMICZNO-FINANSOWA

ANALIZA EKONOMICZNO-FINANSOWA PROGRAM STUDIÓW FINANSE, RACHUNKOWOŚĆ ZARZĄDCZA I CONTROLLING PRZEDMIOT ZAGADNIENIA GODZ. ZAAWANSOWANE NARZĘDZIA RACHUNKOWOŚCI Rachunkowość zarządcza Prognozowanie sprzedaży i kosztów, rachunki optymalizacyjne

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

Świat rzeczywisty i jego model

Świat rzeczywisty i jego model 2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),

Bardziej szczegółowo

Narzędzia Informatyki w biznesie

Narzędzia Informatyki w biznesie Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

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

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS 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

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt

Bardziej szczegółowo

Testowanie i walidacja oprogramowania

Testowanie i walidacja oprogramowania i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja

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

Design thinking zaprojektuj, zbuduj i przetestuj swoje pomysły

Design thinking zaprojektuj, zbuduj i przetestuj swoje pomysły Design thinking zaprojektuj, zbuduj i przetestuj swoje pomysły Cel szkolenia: Termin: 26.11.2016 r. Design thinking jest metodą, która pozwala na bardzo szybkie tworzenie innowacyjnych produktów lub usług,

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

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08 Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.

Bardziej szczegółowo

Specjalizacja: Zarządzanie projektami (I)

Specjalizacja: Zarządzanie projektami (I) Specjalizacja: Zarządzanie projektami (I) Osoba koordynująca: dr inż. Tomasz Pieciukiewicz Tomasz.Pieciukiewicz1@pjwstk.edu.pl Czego uczymy. Umiejętności po ukończeniu specjalizacji. Celem specjalizacji

Bardziej szczegółowo

Podsumowanie wyników ankiety

Podsumowanie wyników ankiety SPRAWOZDANIE Kierunkowego Zespołu ds. Programów Kształcenia dla kierunku Informatyka dotyczące ankiet samooceny osiągnięcia przez absolwentów kierunkowych efektów kształcenia po ukończeniu studiów w roku

Bardziej szczegółowo

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

Platforma Cognos. Agata Tyma CMMS Department Marketing & Sales Specialist atyma@aiut.com.pl. 2011 AIUT Sp. z o. o.

Platforma Cognos. Agata Tyma CMMS Department Marketing & Sales Specialist atyma@aiut.com.pl. 2011 AIUT Sp. z o. o. Platforma Cognos Agata Tyma CMMS Department Marketing & Sales Specialist atyma@aiut.com.pl Business Intelligence - Fakty Kierownicy tracą około 2 godzin dziennie na szukanie istotnych informacji. Prawie

Bardziej szczegółowo

O-MaSE Organization-based Multiagent System Engineering. MiASI2, TWO2,

O-MaSE Organization-based Multiagent System Engineering. MiASI2, TWO2, O-MaSE Organization-based Multiagent System Engineering MiASI2, TWO2, 2017-2018 Materiały Strona poświęcona metodzie O-MaSE http://macr.cis.ksu.edu/projects/omase.html (Multiagent & Cooperative Reasoning

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

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

Bardziej szczegółowo

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

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

Rozpoczęcie, inicjacja (ang. inception

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

Bardziej szczegółowo

Semantyczny Monitoring Cyberprzestrzeni

Semantyczny Monitoring Cyberprzestrzeni Semantyczny Monitoring Cyberprzestrzeni Partnerzy projektu: Katedra Informatyki Ekonomicznej Uniwersytet Ekonomiczny w Poznaniu Partnerzy projektu: Zarys problemu Źródło internetowe jako zasób użytecznych

Bardziej szczegółowo

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens

Bardziej szczegółowo

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i

Bardziej szczegółowo

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

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

Podstawy modelowania programów Kod przedmiotu

Podstawy modelowania programów Kod przedmiotu Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki

Bardziej szczegółowo

Zarządzanie kompetencjami

Zarządzanie kompetencjami Zarządzanie kompetencjami Zarządzanie kompetencjami reprezentuje jeden z najnowszych nurtów zarządzania zasobami ludzkimi. Jako datę początku zainteresowania zarządzaniem kompetencjami w literaturze wskazuje

Bardziej szczegółowo

Użyteczność stron internetowych

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

Bardziej szczegółowo

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura

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

BIM jako techniczna platforma Zintegrowanej Realizacji Przedsięwzięcia (IPD - Integrated Project Delivery)

BIM jako techniczna platforma Zintegrowanej Realizacji Przedsięwzięcia (IPD - Integrated Project Delivery) BIM jako techniczna platforma Zintegrowanej Realizacji Przedsięwzięcia (IPD - Integrated Project Delivery) Dr inż. Michał Juszczyk Politechnika Krakowska Wydział Inżynierii Lądowej Zakład Technologii i

Bardziej szczegółowo

SK01-KA

SK01-KA 2018-1-SK01-KA203-046318 O2 Metodyczny i techniczny przewodnik krok-po-kroku dotyczący wdrażania innowacji w programie studiów medycznych i w naukach pokrewnych Podsumowanie Autorzy: projekt BCIME Disclaimer:

Bardziej szczegółowo

Jak skutecznie wykorzystać system zarządzania JST do poprawy jakości życia mieszkańców?

Jak skutecznie wykorzystać system zarządzania JST do poprawy jakości życia mieszkańców? Jak skutecznie wykorzystać system zarządzania JST do poprawy jakości życia mieszkańców? Konferencja zamykająca realizację innowacyjnego projektu partnerskiego MJUP Krótka prezentacja innowacyjnego projektu

Bardziej szczegółowo

INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH

INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH Informatyka poziom rozszerzony Razem można więcej podstawy pracy

Bardziej szczegółowo

Projekt systemu informatycznego

Projekt systemu informatycznego Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych

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

ALLPLAN SERIA PODSTAWY BIM PRZEWODNIK ZARZĄDZANIA BIM

ALLPLAN SERIA PODSTAWY BIM PRZEWODNIK ZARZĄDZANIA BIM ALLPLAN SERIA PODSTAWY BIM PRZEWODNIK ZARZĄDZANIA BIM CZYM JEST BIM? Building Information Modeling (BIM) Building information modeling to wizualizacja procesowa, która w całym cyklu życia projektu tworzy

Bardziej szczegółowo

SYLABUS DOTYCZY CYKLU KSZTAŁCENIA 2016/ /18 (skrajne daty)

SYLABUS DOTYCZY CYKLU KSZTAŁCENIA 2016/ /18 (skrajne daty) SYLABUS DOTYCZY CYKLU KSZTAŁCENIA 2016/17-2017/18 (skrajne daty) 1.1. PODSTAWOWE INFORMACJE O PRZEDMIOCIE/MODULE Nazwa przedmiotu/ modułu Pracownia dyplomowa magisterskia Kod przedmiotu/ modułu* Wydział

Bardziej szczegółowo

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

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

Bardziej szczegółowo