Obiekty graniczne pomiędzy technikami inżynierii oprogramowania a technikami użyteczności i Kansei
|
|
- Justyna Kowalska
- 8 lat temu
- Przeglądów:
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 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ółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowo> 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ółowoProjektowanie 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ółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Bardziej szczegółowoKarta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
Bardziej szczegółowoKomputerowe 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ółowoZagadnienia (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ółowoPRZEWODNIK 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ółowoNazwa 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ółowoSVN. 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ółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoModel 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ółowoKARTA 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ółowoProjektowanie interakcji
Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoNależ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ółowoOmó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ółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoNarzę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ółowoPRZEWODNIK 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ółowoCo 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ółowoInż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ółowoLaboratorium 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ółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoHCI 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ółowoUML 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ółowoAnaliza 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ółowoWykorzystanie 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ółowoModelowanie 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ółowoDiagramy 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ółowoDiagramy 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ółowoProjekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych
Bardziej szczegółowoPoró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ółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoKurs 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ółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
Bardziej szczegółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoEgzamin / 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ółowoInż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ółowoWykł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ółowoMiASI. 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ółowoWPROWADZENIE 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ółowoInż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ółowoPraktyczne 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ółowoAnaliza 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ółowoDESIGN 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ółowoTester 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ółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Bardziej szczegółowoJAK 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ółowoArchitektura 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ółowoPodstawy 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ółowoCel 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ółowoWZORCE 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ółowoInnowacyjne 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ółowoNarzę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ółowoANALIZA 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ółowoWarsztaty 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
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ółowoNarzę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ółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoModelowanie 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ółowoMonitoring 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ółowoLaboratorium 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ółowoTestowanie 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ółowoFeature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
Bardziej szczegółowoDesign 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ółowoProjekt 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ółowoSpis 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ółowoSpecjalizacja: 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ółowoPodsumowanie 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ółowoCechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz
Cechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz Zofia Kruczkiewicz Wyklad_INP002017_3 1 CMMI (Capability Maturity Model Integration ) -
Bardziej szczegółowoPlatforma 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ółowoO-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ółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoKIERUNKOWE 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ółowoInformatyzacja 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ółowoRozpoczę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ółowoSemantyczny 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ółowoZARZĄ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ółowoAnaliza 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ółowoPYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Bardziej szczegółowoPodstawy 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ółowoZarzą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ółowoUżyteczność stron internetowych
Użyteczność stron internetowych Użyteczność Użyteczność (ang. usability) jest to dziedzina wiedzy dotycząca interaktywnych urządzeń i aplikacji, która określa stopień, w jakim ludzie są w stanie wykonać
Bardziej szczegółowoZARZĄ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ółowoProjekty 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ółowoBIM 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ółowoSK01-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ółowoJak 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ółowoINFORMATYKA 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ółowoProjekt 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ółowoInstrukcja 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ółowoALLPLAN 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ółowoSYLABUS 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ółowoModelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.
Bardziej szczegółowo