KRYTERIA OCENY METODY WSPOMAGAJCEJ INTERAKCJ KLIENT-DOSTAWCA OPROGRAMOWANIA I ICH ZASTOSOWANIE DO METODY WIKLIDO

Podobne dokumenty
1.ZASTOSOWANIE METODY WIKLIDO W PROJEKCIE USPRAWNIENIA PROCESÓW ANALIZY I PROJEKTOWANIA NA BAZIE METODYKI RUP

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 6 Seria: Technologie Informacyjne 2008

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

Cechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz

Goal Question Metrics. Jarosław Kuchta Jakość Systemów Informatycznych

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

Opis metodyki i procesu produkcji oprogramowania

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

Modelowanie i analiza systemów informatycznych

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

Zarzdzanie i inynieria produkcji Studia II stopnia o profilu: A x P. Wykład 15 wiczenia Laboratorium Projekt 15

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

dr inż. M. Żabińska, Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

Analityk i współczesna analiza

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Marek Krętowski Wydział Informatyki PB. Wersja 1.1 IO2 (wyk.

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

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

Wymierne korzyci wynikajce z analizy procesów

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy

Zarzdzanie i inynieria produkcji Studia II stopnia o profilu: A x P

Kryteria dla Dziaania 3.2

Rozdzia I Postanowienia ogólne

Inżynieria oprogramowania (Software Engineering)

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Norma IEEE SPMP

Programowanie Obiektowe

Lista kontrolna umowy z podwykonawc

Podstawy organizacji systemów zarządzania bezpieczeństwem informacji dokumenty podstawowe

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

Narzędzia CASE dla.net. Łukasz Popiel

Zarzdzanie i inynieria produkcji Studia II stopnia o profilu: A P

Inżynieria oprogramowania. Jan Magott

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

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

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 4 Seria: Technologie Informacyjne 2006

Poznanie i przyswojenie przez studentów podstawowych poj z zakresu organizacji i zarzdzania C2

Projekt Kompetencyjny - założenia

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends

Zarzdzanie i inynieria produkcji Studia I stopnia o profilu: A P

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Etapy życia oprogramowania

Projektowanie systemów informatycznych. wykład 6

Cloud Computing - czego wymaga od dostawcy usług w zakresie bezpieczestwa. Telekomunikacja Polska S.A. Andrzej Karpiski Łukasz Pisarczyk

Formułowanie i zastosowanie pryncypiów architektury korporacyjnej w organizacjach publicznych

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

Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy

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

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje studentów rozpoczynających studia w roku akademickim 2015/2016

Regulamin Audytu Wewntrznego Urzdu Miasta w Ktrzynie

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

PODSTAWY DIAGNOSTYKI MASZYN

Instrukcja dla pracowników Uniwersytetu Rzeszowskiego.

Jolanta Łukowska Małgorzata Pakowska Stanisław Stanek Mariusz ytniewski

Zeszyty Naukowe UNIWERSYTETU PRZYRODNICZO-HUMANISTYCZNEGO w SIEDLCACH Nr 97 Seria: Administracja i Zarz dzanie 2013

Studium przypadku Case Study CCNA2-ROUTING

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Załącznik KARTA PRZEDMIOTU. KARTA PRZEDMIOTU Wydział Automatyki, Elektroniki i Informatyki, Rok akademicki: 2011/2012

KIERUNKI ROZWOJU W INYNIERII JAKOCI

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT

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

Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny?

DZIAŁ ZARZĄDZANIA RYZYKIEM INFORMATYCZNYM. Strategia i Polityka Bezpieczeństwa Systemów Informatycznych. Wykład. Aleksander Poniewierski

Inżynieria oprogramowania (Software Engineering)

Centrum zarządzania bezpieczeństwem i ciągłością działania organizacji

Specjalno techniczna 2. Inynieria produkcji w przemyle maszynowym. Zarzdzanie i inynieria produkcji Studia II stopnia o profilu: A x P

ANALIZA EKONOMICZNO-FINANSOWA

NA , R.

NOWOCZESNE ROZWI ZANIA IT KLUCZEM DO ZDOBYCIA PRZEWAGI KONKURENCYJNEJ PRZEDSI BIORSTW PRZEMYSŁU ROLNO-SPO YWCZEGO W POLSCE

Ocena Zasobów Pomocy Spo ecznej Miasta M awa za 2016 rok

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Zakres wykładu. Podstawy InŜynierii Oprogramowania

tel. (+48 81) /22 fax (+48 81) Wykład Ćwiczenia Laboratorium Projekt

Skuteczny nadzór nad zgodnością

WPROWADZENIE DO UML-a

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

WIEDZA EFEKTY KSZTA CENIA z Ustawy o ZSK 1 :

IATF 16949:2016 Zatwierdzone Interpretacje

Regulamin uczestnictwa w systemie patronatu Ministerstwa Gospodarki i Pracy w zakresie szkole na temat instrumentów polityki strukturalnej UE

DIAGNOZOWANIE STANÓW ZDOLNO CI JAKO CIOWEJ PROCESU PRODUKCYJNEGO

Promotor: dr inż. Krzysztof Różanowski

Zarządzanie inicjatywami i wymaganiami w projektach IT

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań

Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 3 Zbigniew Misiak (BOC IT Consulting)

Dr Katarzyna Grzesiak-Koped

Uchwała Nr Rady Miasta Rejowiec Fabryczny

Dobre wdrożenia IT cz. I Business Case.

6.3 Opłata za dostpno jako komponent wynagrodzenia partnera prywatnego

ZARZDZENIE NR 210/06 PREZYDENTA MIASTA ZIELONA GÓRA. z dnia 3 marca 2006 r. w sprawie uytkowania i gospodarowania majtkiem Urzdu Miasta Zielona Góra.

UCHWAŁA NR 0150/ XLVIII / / 06 RADY MIASTA TYCHY z dnia 29 czerwca 2006 roku

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

MINISTERSTWO INFRASTRUKTURY SPRAWOZDANIE Z REALIZACJI PILOTAOWEGO PROGRAMU BUDOWY DOMÓW SOCJALNYCH

Program Współpracy Gminy Michałowo z Organizacjami Pozarzdowymi na rok 2008.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

PROGRAM WSPÓŁPRACY POWIATU KŁOBUCKIEGO Z ORGANIZACJAMI POZARZDOWYMI W 2005 ROKU.

ZIP 2 S _0 Jzyk wykładowy: polski

Zarzdzanie i Inynieria Produkcji Studia drugiego stopnia o profilu: A P. Wykład 15 wiczenia 30 Laboratorium Projekt

KARTA OCENY JEDNOSTKI NAUKOWEJ

Transkrypt:

ROZDZIA 99 KRYTERIA OCENY METODY WSPOMAGAJCEJ INTERAKCJ KLIENT-DOSTAWCA OPROGRAMOWANIA I ICH ZASTOSOWANIE DO METODY WIKLIDO W rozdziale przedstawiono metod3 Wspomagania Interakcji KLIent-Dostawca Oprogramowania (WIKLIDO) oraz wyja8niono w jaki sposób wykorzystano metod3 GQM (ang. Goal Question Metrics) do systematycznego wywiedzenia metryk oceny tej metody. 1. WPROWADZENIE Problem interakcji (wspó;pracy) klient-dostawca jest istotnym elementem przedsi3wzi3< pozyskiwania oprogramowania. Udzia;owcy tego problemu reprezentuj> róne perspektywy cz3sto wywodz> si3 z rónych kultur organizacyjnych, pochodz> z rónych dziedzin i grup zawodowych o zrónicowanym poziomie do8wiadcze, wiedzy i wykszta;cenia. Powoduje to, e wspó;praca klient-dostawca oprogramowania stanowi jeden z g;ównych obszarów ryzyka [8] w przedsi3wzi3ciach informatycznych, a niedostatki tej wspó;pracy s> jednym z g;ównych zagroe sukcesu takich przedsi3- wzi3<. Inynieria oprogramowania dysponuje wieloma standardami i praktykami, które w swoim zakresie mieszcz> problem wspó;pracy i zawieraj> wskazówki dotycz>ce obnienia zwi>zanych z nim ryzyk. W8ród standardów, które obejmuj> zagadnienia wspó;pracy mona wymieni< ITIL (ang. Information Technology Infrastructure Library) [5], CMMI-ACQ (ang. Capability Maturity Model Integration for Acquisition) [12], COBIT (ang. Control Objectives for Information and related Technology) [4], IBM RUP (ang. Rational Unified Process) [11], ISO 12207:2008 (Systems and software engineering - Software life cycle processes) [6], IEEE Std 828-2005 (IEEE Standard for Software Configuration Management Plans) [3], IEEE Std 1062-1998 (IEEE recommended practice for software acquisition) [1], IEEE Std 830-1998 (IEEE recommended practice for software requirements specifications) [2]. Jednak standardy te, ze wzgl3du na ich zakres naley uzna< za ogólne, jedynie pobienie traktuj>ce Krzysztof Wyrzykowski, Janusz Górski: Politechnika Gdaska Katedra Inynierii Oprogramowania; ul. Gabriela Narutowicza 11/12, 80-952 Gdask; {jango,kwyrzyk}@eti.pg.gda.pl

K. Wyrzykowski, J. Górski kwestie wspó;pracy klient-dostawca oprogramowania. Ograniczaj> si3 one do wprowadzenia taksonomii poj3< oraz ogólnych zalece dotycz>cych post3powania wspó;- pracuj>cych stron. Nie daj> wystarczaj>cej podstawy do formalizacji tego obszaru, a co za tym idzie nie tworz> warunków do opracowania skutecznych rozwi>za wspomagaj>cych wspó;prac3. Jako uzupe;nienie standardów i jednoczesne wsparcie w ich osi>ganiu autorzy niniejszej pracy proponuj> nowe podej8cie do modelowania i wspierania wspó;pracy klienta i dostawcy oprogramowania. Metoda ta, nazwana metod> Wspomagania Interakcji KLIent-Dostawca Oprogramowania (WIKLIDO) polega na opracowaniu modelu interakcji dla klienta i dostawcy w ramach przedsi3wzi3< pozyskiwania oprogramowania, a nast3pnie wykorzystywaniu tego modelu do usprawnienia procesu pozyskiwania oprogramowania realizowanego z udzia;em wspó;pracuj>cych stron. W rozdziale zawarto wprowadzenie do metody WIKLIDO oraz w systematyczny sposób wywiedziono zestaw metryk s;u>cych do oceny tej metody. Ponadto krótko opisano dwa studia przypadków zwi>zane z zastosowaniem metody, które w toku dalszych bada pos;u> do zebrania danych w celu wyznaczenia warto8ci zaproponowanych metryk. 2. METODA WIKLIDO Rysunek 1 przedstawia kontekst uytkowy metody WIKLIDO. Metoda zak;ada wykorzystanie trzech komponentów, które zaprezentowano na rysunku. <<framework>> WIKLIDO Dostawca Oprogramowania <<model>> MIKDO <<model>> BWIP Klient Oprogramowania Uytkownik Modelu <<model>> MIIPU Inynier Procesu Rys. 1 Metoda WIKLIDO w kontek8cie uytkowym W ramach modelu przedstawionego na rysunku 1 wyróniono Inyniera Procesu rol3 zwi>zan> ze wspomaganiem zastosowania metody, oraz Uytkownika Modelu - udzia;owca, na rzecz którego metoda jest stosowana. Uytkownikami modelu s> w szczególno8ci g;owni aktorzy procesu pozyskiwania oprogramowania: klient i dostawca oprogramowania. 2

Metryki oceny metody WIKLIDO Architektura metody WIKLIDO obejmuje: 1. Model Interakcji Klient-Dostawca Oprogramowania (MIKDO) powstaje w wyniku procesu modelowania i opisuje interakcje klient-dostawca oprogramowania. Sk;adnikami MIKDO s> abstrakcje metamodelu SPEM2 [9] w tym wzorce interakcji klient-dostawca oprogramowania. 2. Model Interakcji In"ynier Procesu-U"ytkownik (MIIPU) to model interakcji inyniera procesu z uytkownikami modeli (reprezentantami dostawcy i klienta oprogramowania). G;ównymi sk;adnikami MIIPU s>: definicje podstawowych poj3< modelowania interakcji, wzorce interakcji inynier procesu-uytkownik modelu. 3. Baza Wiedzy In"yniera Procesu (BWIP) jest metodycznym zapleczem in- yniera procesu, zawiera praktyki na temat modelowania interakcji klientdostawca oprogramowania. G;ównymi sk;adnikami BWIP s>: metamodel interakcji klient-dostawca oprogramowania, definicje podstawowych poj3< modelowania interakcji klient-dostawca oprogramowania, wzorce interakcji inynier procesu-uytkownik modelu, szablony interakcji klient-dostawca oprogramowania, przyk;ady wype;nionych szablonów interakcji klient-dostawca oprogramowania, listy kontrolne dla szablonów interakcji klient-dostawca oprogramowania w tym g;ównych abstrakcji metamodelu SPEM2 [3]. Zastosowanie metody WIKLIDO polega na koordynowanej przez inyniera procesu (z udzia;em klienta i dostawcy oprogramowania) budowie modelu MIKDO [7], a nast3pnie wykorzystaniu tego modelu do wspomagania procesu interakcji klientdostawca w przedsi3wzi3ciach pozyskiwania oprogramowania. 3. STUDIA PRZYPADKÓW W ramach prac badawczych nad metod> WIKLIDO zrealizowano przy wspó;- pracy z partnerami przemys;owymi dwa studia przypadków. W pierwszym przypadku opracowano MIKDO dla przedsi3wzi3cia pozyskania szpitalnego systemu informatycznego 1 [10]. Opracowany model wykorzystano do wspomagania wdroenia takiego systemu w szpitalu. W drugim przypadku opracowano MIKDO dla przedsi3wzi3cia pozyskiwania Sytemu Monitoringu i Kontroli Finansowej 2. Model zosta; wykorzystywany jako standard analityczno-projektowy dla obu wspó;pracuj>cych stron. 1 Dostawca: ISH Polska, Klient: Swissmed Centrum Zdrowia, Produkt: system emedsolution 2 Dostawca: Comarch Systemy Informatyczne, Klient: Ministerstwie Finansów, Produkt: sys- 3

K. Wyrzykowski, J. Górski Przeprowadzone studia przyczyni;y si3 do uszczegó;owienia architektury metody (trzy komponenty) i jej udoskonalenia (zawarto8< komponentów). Stan ten sta; si3 podstaw> do planowania eksperymentów oceniaj>cych. Zaplanowano w szczególno8ci ocen3 metody WIKLIDO w nast3puj>cych aspektach: 1. Baza Wiedzy Inyniera Procesu (BWIP) - pod wzgl3dem uyteczno8ci. 2. Model Interakcji Inynier Procesu-Uytkownik (MIIPU) - pod wzgl3dem uyteczno8ci. 3. Proces modelowania interakcji klient-dostawca oprogramowania - pod wzgl3dem wydajno8ci. 4. Model Wspó;pracy Klient-Dostawca Oprogramowania (MIKDO) - pod wzgl3dem uyteczno8ci. 5. Proces wykorzystania MIKDO - pod wzgl3dem efektywno8ci. Do systematycznego wywiedzenia metryk s;u>cych osi>gni3ciu zdefiniowanych wyej celów pomiarowych zastosowano metod3 GQM (ang. Goal Question Metrics)[13]. 4. METRYKI OCENY METODY WIKLIDO 4.1. METRYKI OCENY BWIP Tabela 2. Cel oceny MWIP Zbada< W celu Pod wzgl3dem Z perspektywy W kontek8cie Baz' Wiedzy In"yniera Procesu oceny u"yteczno(ci in"yniera procesu eksperymentu w (rodowisku przemys)owym Dla oceny uyteczno8ci BWIP wywiedziono nast3puj>ce pytania i metryki: P1: Czy )atwo opanowa+ wiedz' zawart, w BWIP? M1: 8rednia z ocen ;atwo8ci opanowania wiedzy zawartej w BWIP P2: Czy BWIP wspiera in"yniera procesu? M1: 8rednia z ocen ;atwo8ci uytkowania BWIP tem SIMIK (System Informatyczny Monitoringu i Kontroli Finansowej Funduszy Strukturalnych i Funduszu Spójno8ci) 4

Metryki oceny metody WIKLIDO M2: 8rednia z ocen ;atwo8ci stosowania szablonów interakcji klient-dostawca oprogramowania M3: 8rednia z ocen przydatno8ci wzorców interakcji inynier procesuuytkownik modelu M4: 8rednia z ocen szczegó;owo8ci wzorców interakcji inynier procesuuytkownik modelu M5: 8rednia z ocen przydatno8ci list kontrolnych Autorzy metody przyjmuj> iteracyjny proces udoskonalania uyteczno8ci BWIP. Rozstrzygni3cie odpowiedzi dla P1 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich z ocen dla M1. Rozstrzygni3cie odpowiedzi dla P2 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich arytmetycznych uzyskanych dla M1 M5. Zakres odpowiedzi dla P1 i P2 ustalono w przedziale od 1 do 5. Za pozytywna odpowiedv na postawione pytania przyj3to uzyskanie 8redniej arytmetycznej W 3. 4.2. METRYKI OCENY MIIPU Tabela 3. Cel oceny MIIPU Zbada< W celu Pod wzgl3dem Z perspektywy W kontek8cie Model Interakcji In"ynier Procesu-U"ytkownik oceny u"yteczno(ci u"ytkownika modelu eksperymentu w (rodowisku przemys)owym Dla oceny uyteczno8ci MIIPU wywiedziono nast3puj>ce pytania i metryki: P1: Czy )atwo opanowa+ wiedz' zawart, w modelu MIIPU? M1: 8rednia z ocen ;atwo8ci opanowania wiedzy modelu P2: Czy model MIIPU wspiera u"ytkownika? M1: 8rednia z ocen ;atwo8ci uytkowania modelu M2: 8rednia z ocen przydatno8ci wzorców interakcji inynier procesuuytkownik M3: 8rednia z ocen kompletno8ci wzorców interakcji inynier procesuuytkownik Autorzy metody przyjmuj> iteracyjny proces udoskonalania uyteczno8ci MIIPU. Rozstrzygni3cie odpowiedzi dla P1 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich z ocen dla M1. Rozstrzygni3cie odpowiedzi dla P2 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich arytmetycznych uzyskanych dla M1 M3. Zakres odpowiedzi dla P1 i P2 ustalono w 5

K. Wyrzykowski, J. Górski przedziale od 1 do 5. Za pozytywna odpowiedv na postawione pytania przyj3to uzyskanie 8redniej arytmetycznej W 3. 4.3. METRYKI OCENY PROCESU MODELOWANIA INTERAKCJI KLIENT- DOSTAWCA OPROGRAMOWANIA Tabela 4. Cel oceny procesu modelowania interakcji klient-dostawca oprogramowania Zbada< W celu Pod wzgl3dem Z perspektywy W kontek8cie proces modelowania interakcji klient-dostawca oprogramowania oceny wydajno(ci in"yniera procesu i u"ytkowników MIKDO eksperymentu w (rodowisku przemys)owym Dla oceny wydajno8ci procesu modelowania interakcji wywiedziono nast3puj>ce pytania i metryki: P1: Jaka jest pracoch)onno(+ modelowania interakcji klient-dostawca oprogramowania? M1: pracoch;onno8< modelowania interakcji klient-dostawca oprogramowania M2: pracoch;onno8< zaangaowanych udzia;owców uytkowników modelu w specyfikowanie interakcji M3: pracoch;onno8< weryfikacji wyników modelowania przez uytkowników modelu M4: pracoch;onno8< merytorycznego przeszkolenia inyniera procesu do stosowania metody WIKLIDO M5: liczba uytkowników MIKDO zaangaowanych w proces modelowania interakcji Autorzy metody przyjmuj> iteracyjny proces pomiaru wydajno8ci procesu modelowania interakcji klient-dostawca oprogramowania. Uzyskanie odpowiedzi dla P1 nast>pi na podstawie uzyskanych danych dotycz>cych pracoch;onno8ci zwi>zanej z wytworzeniem MIKDO oraz alokacji zasobów ludzkich w proces modelowania interakcji klient-dostawca oprogramowania. Pomiar wydajno8ci b3dzie nast3powa; po kadej aktualizacji sk;adników metody WIKLIDO. 4.4. METRYKI OCENY MIKDO Tabela 5. Cel oceny Modelu Interakcji Klient-Dostawca Oprogramowania 6

Metryki oceny metody WIKLIDO Zbada< W celu Pod wzgl3dem Z perspektywy W kontek8cie Model Interakcji Klient-Dostawca Oprogramowania oceny u"yteczno(ci klientów MIKDO eksperymentu w (rodowisku przemys)owym Dla oceny uyteczno8ci MIKDO wywiedziono nast3puj>ce pytania i metryki: P1: Czy )atwo opanowa+ wiedz' zawart, w modelu MIKDO? M1: 8redni stopie ;atwo8ci opanowania wiedzy modelu przez jego uytkowników P2: Czy model MIKDO wspiera klienta oprogramowania? M1: 8rednia z ocen ;atwo8ci uytkowania modelu M2: 8rednia z ocen przydatno8ci wzorców interakcji klient-dostawca oprogramowania M3: 8rednia z ocen wsparcia dla analizy potencja;u dla pozyskiwania oprogramowania M4: 8rednia z ocen poprawy zrozumienia swojej roli w interakcji z dostawc> M5: 8rednia z ocen wsparcia dla harmonizacji dzia;a klienta z innymi jego procesami wynikaj>cymi z jego statusowej dzia;alno8ci M6: 8rednia z ocen uszczegó;owienia kluczowych zada interakcji M7: 8rednia z ocen wsparcia dla opracowania koncepcji interakcji z dostawc> M8: 8rednia z ocen wsparcia dla ci>g;ego usprawniania interakcji z dostawc> M9: 8rednia z ocen moliwo8ci ponownego wykorzystania MIKDO dla innego przedsi3wzi3cia pozyskiwania oprogramowania P3: Czy model MIKDO wspiera dostawc' oprogramowania? M1: 8rednia z ocen ;atwo8ci uytkowania modelu M2: 8rednia z ocen przydatno8ci wzorców interakcji klient-dostawca oprogramowani M3: 8rednia z ocen wsparcia dla analizy potencja;u dla dostarczania oprogramowania M4: 8rednia z ocen poprawy zrozumienia swojej roli w interakcji z klientem M5: 8rednia z ocen wsparcia dla harmonizacji dzia;a dostawcy z innymi jego procesami wynikaj>cymi z jego statusowej dzia;alno8ci M6: 8rednia z ocen uszczegó;owienia kluczowych zada interakcji M7: 8rednia z ocen wsparcia dla opracowania koncepcji interakcji z klientem M8: 8rednia z ocen wsparcia dla ci>g;ego usprawniania interakcji z klientem M9: 8rednia z ocen moliwo8ci ponownego wykorzystania MIKDO dla innego przedsi3wzi3cia pozyskiwania oprogramowania P4: Czy MIKDO wspiera identyfikacj' ryzyk wspó)pracy? M1: liczba zidentyfikowanych na podstawie MIKDO ryzyk wspó;pracy wynikaj>cych ze strony klienta 7

K. Wyrzykowski, J. Górski M2: liczba zidentyfikowanych na podstawie MIKDO ryzyk wspó;pracy wynikaj>cych ze strony dostawcy Autorzy metody przyjmuj> iteracyjny proces udoskonalania uyteczno8ci MIK- DO. Rozstrzygni3cie odpowiedzi dla P1 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich z ocen dla M1. Rozstrzygni3cie odpowiedzi dla P2 i P3 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich arytmetycznych uzyskanych dla poszczególnych metryk. Dla P4 rozstrzygni3cie odpowiedzi nast>pi na podstawie liczby zidentyfikowanych ryzyk wspó;pracy. Zakres odpowiedzi dla P1 P3 ustalono w przedziale od 1 do 5. Za pozytywna odpowiedv na postawione pytania przyj3to uzyskanie 8redniej arytmetycznej W 3. Dla P4 przyj3to uzyskanie pozytywnej odpowiedzi je8li MIKDO umoliwi identyfikacj3 minimum 1 ryzyka wspó;pracy klient-dostawca oprogramowania, niezalenie od w;a- 8ciciela ryzyka. 4.5. METRYKI OCENY PROCESU WYKORZYSTANIA MIKDO 8 Tabela 6. Cel oceny procesu wykorzystania MIKDO Zbada< W celu Pod wzgl3dem Z perspektywy W kontek8cie proces interakcji klient-dostawca oprogramowania w oparciu o Model Interakcji Klient-Dostawca Oprogramowania oceny efektywno(ci klientów MIKDO eksperymentu w (rodowisku przemys)owym Dla oceny efektywno8ci procesu wspó;pracy w oparciu o MIKDO wywiedziono nast3puj>ce pytania i metryki: P1: Jaka jest efektywno(+ interakcji opartej o MIKDO z perspektywy klienta oprogramowania? M1: 8rednia z ocen zaufania klienta do dostawcy M2: 8rednia z ocen formalizacji wspó;pracy M3: 8rednia z ocen wsparcia dla dokumentowania procesu wspó;pracy M4: 8rednia z ocen wsparcia dla komunikacji z dostawc> M5: 8rednia z ocen wsparcia dla rozwi>zywania sytuacji konfliktowych M6: 8rednia z ocen wsparcia dla pozyskania dostawcy oprogramowania o najwi3kszym potencjale do efektywnej wspó;pracy P2: Jak jest efektywno(+ interakcji opartej o MIKDO z perspektywy dostawcy oprogramowania?

Metryki oceny metody WIKLIDO M1: 8rednia z ocen zaufania dostawcy do klienta oprogramowania M2: 8rednia z ocen formalizacji wspó;pracy M3: 8rednia z ocen wsparcia dla dokumentowania procesu wspó;pracy M4: 8rednia z ocen wsparcia dla komunikacji z dostawc> M5: 8rednia z ocen wsparcia dla rozwi>zywania sytuacji konfliktowych Autorzy metody przyjmuj> iteracyjny proces pomiaru efektywno8ci procesu interakcji klient-dostawca oprogramowania w oparciu o model MIKDO. Rozstrzygni3cie odpowiedzi dla P1 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich arytmetycznych uzyskanych dla M1 M6. Rozstrzygni3cie odpowiedzi dla P2 nast>pi na podstawie uzyskanej 8redniej arytmetycznej ze wszystkich 8rednich arytmetycznych uzyskanych dla M1 M5. Zakres odpowiedzi dla P1 i P2 ustalono w przedziale od 1 do 5. Za pozytywna odpowiedv na postawione pytania przyj3to uzyskanie 8redniej arytmetycznej W 3. Pomiar efektywno8ci b3dzie nast3powa; po kadej aktualizacji sk;adników metody WIKLIDO. 5. PODSUMOWANIE W metodzie WIKLIDO zastane ocenione: 1. dwa procesy (proces modelowania wspó;pracy, proces wykorzystania MIKDO), 2. dwa zasoby (MWIP, MIIPU) oraz 3. jeden produkt (MIKDO). Z wywiedzionych metryk wynika, e zdecydowana wi3kszo8< cech pomiarowych ma charakter jako8ciowy, a uzyskane wyniki b3d> zalene od subiektywnej oceny uytkowników modeli oraz uczestników procesu wspó;pracy. Wynika to z faktu, i w zagadnieniu interakcji (wspó;pracy) klient-dostawca oprogramowania istotne s> czynniki natury psychologiczno-socjologicznej, takie jak komunikacja wspó;pracuj>cych stron, dobre zrozumienia podstawowych poj3< czy zbudowanie atmosfery zaufania do partnera. Do oceny metody WIKLIDO zdecydowano si3 wy;>cznie na eksperymenty w 8rodowisku przemys;owym, gdy uzyskanie nawet przyblionych warunków w 8rodowiska akademickim uznano za niemoliwe. Do zebrania danych pos;uy ankieta. Respondentami ankiety b3d> wspó;pracuj>cy (b3d>cy w interakcji) przedstawiciele klienta i dostawcy oprogramowania danego przedsi3wzi3cia informatycznego. 9

K. Wyrzykowski, J. Górski LITERATURA DO ROZDZIAXU [1] IEEE recommended practice for software acquisition, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=16011&arnumber=741938&punumber= 5977 2009 [2] IEEE recommended practice for software requirements specifications, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=15571&arnumber=720574&punumber= 5841-2009 [3] IEEE Standard for Software Configuration Management Plans, http://ieeexplore.ieee.org/xpls/abs_all.jsp?tp=&isnumber=32241&arnumber=1502775&punumber=10 048 2009 [4] Information Systems Audit and Control Association: Control Objectives for Information and Related Technology 4.1 2007, http://www.isaca.org/content/navigationmenu/members_and_leaders/cobit6/obtain_cobit/obt ain_cobit.htm - 2009 [5] Information Technology Infrastructure Library v3 2007: Official ITIL Website. http://www.itilofficialsite.com/home/home.asp - 2009 [6] ISO 12207:2008 Systems and software engineering - Software life cycle processes, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43447 2009 [7] K. Wyrzykowski, J. Górski: Modelowanie wspó;pracy klienta i dostawcy w przedsi3wzi3ciach pozyskiwania oprogramowania. I Ma;opolska Konferencja Zarz>dzanie Projektem. Kraków 2007 [8] McConnell S.: Rapid Development, Microsoft Press, 1996. [9] Object Management Group, Software Process Engineering Metamodel Specification, Version 2.0, 2005, http://www.omg.org/docs/ptc/07-11-01.pdf [10]P. D>browski, M. Jakubowski, J. Górski, K. Wyrzykowski: Wspieranie wspó;pracy klienta i dostawcy szpitalnego systemu informatycznego emedsolution w organizacji medycznej Swissmed. Trzy perspektywy. Ogólnopolski Przegl>d Medyczny nr 12.2007 [11]Rational Unified Process v7.01, 2008. [12]Software Engineering Institute: Capability Maturity Model Integration for Acquisition, Version 1.2 2007, http://www.sei.cmu.edu/pub/documents/07.reports/07tr017.pdf - 2009 [13]Solingen R. van, Berghout E.: The Goal/Question/Metric method: A practical guide for quality improvement of software development, McGraw-Hill, 1999. 10