Ocena jakości wyrobu programowego przez użytkowników

W proponowanych przez SEI (Software Engineering Institute) oraz w treści standardów rodziny ISO 9000 metodach poprawy jakości przyjmuje się ogólne założenie, że dobrze zarządzane i wykonywane procesy owocują wysokiej jakości wyrobami programowymi. Nie kwestionując konieczności ulepszania szeroko rozumianych procesów wytwórczych oraz innych z nimi związanych, uznano za celowe szersze niż dotąd włączenie użytkowników do działań prowadzących do poprawy jakości oprogramowania. Ocena jakości wyrobów programowych przez użytkowników wydaje się mało, jak dotąd, wykorzystywaną możliwością poprawy jakości oprogramowania.Przyjęto, że poziom satysfakcji użytkownika jest pochodną jakości użytkowanego wyrobu programowego. Celem prezentowanych badań było wypracowanie metodyki konstruowania kwestionariusza ankiety oceny ziomu satysfakcji użytkownika systemu informatycznego średniej wielkości w kategorii baz danych, następnie budowa kilku ankiet, ankietyzacja w warunkach rzeczywistych, to jest w zakładach pracy praktycznie stosujących wybrane oprogramowanie, analiza rezultatów i wyciągniecie wniosków z eksperymentu. Przedmiotem badań były cztery różne programy użytkowane w wybranych zakładach pracy. Badania nie miały na celu ocen porównawczych i wyboru ewentualnego lidera wśród badanych programów, ani też znalezienia wzorowego oprogramowania w wybranej kategorii. Znaczna część pytań kwestionariuszy jest wspólna dla opracowanych ankiet.

Przeprowadzono cztery ankiety [KMWA2003], posługując się opracowanymi w tym celu kwestionariuszami o podobnej budowie. W układzie pytań kwestionariuszy starano się uwzględnić rozmaite aspekty jakości wyrobu programowego. Zebrano wyniki poszczególnych ankiet i sformułowano wspólne wnioski. Przedstawiono aspekty etyczne i społeczne jakości oprogramowania, które, zdaniem autorki, powinny być w szerszym niż dotąd stopniu brane pod uwagę podczas ocen jakości wyrobów programowych, zwłaszcza o zasięgu krajowym.

W treści standardu ISO 9000:2000 jakość określona jest jako stopień, w jakim zbiór inherentnych właściwości spełnia wymagania. Z kolei wymagania są zdefiniowane w punkcie 3.1.2 jako potrzeba lub oczekiwanie, które zostało ustalone, przyjęte zwyczajowo lub jest obowiązkowe. W odniesieniu do oprogramowania jakość definiowana jest zbiorem charakterystyk decydujących o zdolności wyrobu do spełnienia wyrażonych i implikowanych potrzeb [ISO 9126-1:2001].Problematyka jakości wyrobów programowych obejmuje, zdaniem autorki, znacznie szerszy obszar działań, aniżeli zwykło się ujmować. Uzyskanie oprogramowania wysokiej jakości wymaga łączenia stosowania metod i generowania kryteriów oceny wywodzących się z:

• Inżynierii, w szczególności inżynierii oprogramowania,

• Zarządzania,

• Psychologii,

• Etyki.

Włączenie pierwszych dwóch wyżej wymienionych obszarów nie budzi wątpliwości. Inżynieria programowania została wyodrębniona jako osobna dyscyplina techniczna w celu zapewnienia jakości oprogramowania, odpowiedniej do potrzeb jego odbiorców [GÓRS1999]. Zarządzanie jakością jest, jak nazwa wskazuje, elementem zarządzania, które obejmuje procesy planowania, organizowania prac, przewodzenia i nadzoru. Obowiązują przy tym przyjęte w skali światowej standardy jakości, z rekomendowanym ostatnio przez ISO podejściem procesowym włącznie. Ocenę dojrzałości procesów wytwórczych oprogramowania prowadzi się zgodnie z modelem CMM.

Zasada orientacji na klienta jest wymieniona na pierwszym miejscu wśród ośmiu zasad zarządzania jakością, zawartych w treści ostatniej wersji standardu ISO 9000. Wdrożenie i stosowanie tych zasad poleca się kierownictwu organizacji. W wydanym, po opublikowaniu polskiej wersji standardu, komentarzu [KOME2001] zebrano następujące formy wyrażania orientacji na klienta (podkreślenie własne):

• Badanie i zrozumienie potrzeb i oczekiwań klienta,

• Zapewnienie, że cele organizacji są powiązane z potrzebami i oczekiwaniami klienta,

• Komunikowanie potrzeb i oczekiwań klienta w całej organizacji,

• Pomiary zadowolenia klienta i podejmowanie działań na podstawie wyników,

• Systematyczne zarządzanie relacjami z klientem,

• Zapewnienie wyważonego podejścia między zadowoleniem klientów i innych stron zainteresowanych (takich jak właściciele, pracownicy, dostawcy, finansiści, lokalne społeczności i całe społeczeństwo).

Korzyścią z orientacji na klienta jest zwiększenie udziału dostawcy w rynku oraz kontynuowanie relacji biznesowych ze strony zadowolonego klienta, traktowanego jako kontrahenta podpisującego umowy, a nie indywidualnego pracownika, który używa oprogramowania w swej codziennej pracy. W miarę postępów w zakresie kompleksowej informatyzacji firm i instytucji bezpośredni użytkownicy wyrobów programowych mogą być już uznani za odbiorców masowych, jak to ma na przykład miejsce w przypadku mebli lub samochodów. Pośrednimi użytkownikami oprogramowania są również klienci i petenci nabywców oprogramowania. Odwołując się do ocen tak szeroko rozumianych użytkowników, nie sposób pominąć kwestii ich różnorodności. Życzliwy bądź graniczący z niechęcią stosunek do oprogramowania może wynikać z indywidualnych preferencji, rozmaitych cech osobowych i wcześniejszych doświadczeń.

Jak dotąd, nie angażuje się psychologów do analiz osobowości przyszłych użytkowników oprogramowania. W niewielkim zakresie prowadzi się prace w zakresie cech osobowości i preferencji jego autorów [TEAG1998]. Rekomendowane przez SEI metody diagnozy i poprawy procesów, to jest CBA IPI (CMM-Based Appraisal for Internal Process Improvement) oraz IDEAL (Initiating, Diagnosing, Establishing, Acting, Learning) [DUNA2001], nie odwołują się do ocen wyrobów programowych przez użytkowników. Być może wynika to częściowo z militarnego rodowodu zamówień dla SEI, jak również z przekonania o istnieniu wszystkowiedzących ekspertów inżynierii oprogramowania.

Uznanie dobrej jakości wyrobu programowego wymaga, aby cele przedsięwzięcia i cały proces wytwórczy spełniał wymogi etyczne. Analiza problemów etycznych i społecznych w inżynierii oprogramowania oraz formułowanie zasad etyki dla potrzeb tworzenia i użytkowania wyrobów IT doczekały się określenia infoetyki i są przedmiotem prezentacji i dyskusji na konferencjach z cyklu ETHICOMP [ETHI2001]. Przekonanie graniczące z wiarą, że nowe technologie zawsze przynoszą postęp społeczny, jest raczej przejawem słabej pozycji humanistów we współczesnym świecie, a nie niepodważalnym pewnikiem.

Przedmiotem oceny były stosowane praktycznie systemy informatyczne lub ich wybrane podsystemy: moduły Ruch Chorych i Apteka Szpitalna systemu Eskulap 2000 używanego w Samodzielnym Publicznym Zakładzie Opieki Zdrowotnej w Wolsztynie, system PROMIS (moduły: Gospodarka Materiałowa, Środki Trwałe, Sprzedaż, Kadry i Płace), funkcjonujący w Zakładach Produkcji Betonów KomórkowychPrefbet Sp. z o. o. w Powodowie, programy (EWID99, SIŁY i ŚRODKI, PODZIAŁ BOJOWY oraz WODA2000) używane w Komendzie Powiatowej Państwowej Straży Pożarnej w Wolsztynie i Grodzisku Wielkopolskim oraz system Info-Expert, wykorzystywany przez agentów i firmy ubezpieczeniowe, prowadzące ubezpieczenia komunikacyjne pojazdów.Treść ankiet nie ograniczała się do cech funkcjonalnych wyrobu programowego. Brano pod uwagę atrybuty jakości ujęte w sześć charakterystyk, rekomendowanych do oceny jakości wewnętrznej i zewnętrznej oprogramowania wg ISO 9126-1:2001. Dużą wagę przypisano ocenie użyteczności (usability), nazywanej jakością użytkową [SIKO2000], którą norma ISO 9241-11 definiuje jako stopień, w jakim produkt może być wykorzystany przez użytkownika do osiągnięcia określonych celów ze sprawnością, efektywnością i satysfakcją w określonym kontekście użycia produktu. Analogiczne znaczenie ma jakość stosowania (quality in use), definiowana w punkcie B.23 normy ISO 9126-1:2001.

Ocena jakości użytkowej ze swej istoty obarczona jest dozą subiektywizmu. Według Nielsena [NIEL1995] wyrób programowy będzie uznany za użyteczny, jeśli jest łatwy do opanowania (easy to learn), efektywny w użyciu (efficient to use), łatwy do zapamiętania (easy to remember), kryje niewiele błędów (few errors) oraz okazuje się przyjemny w użyciu (pleasant to use). Innymi słowy, daje się opisać zbiorem charakterystyk opisujących produktywność, łatwość zrozumienia, nauczenia się obsługi i stosowania w praktyce. Jakość użytkowa jest wynikową jakości technicznej wyrobu oraz jakości ergonomicznej; nie wynika jedynie z potrzeb zadań przypisanych do konkretnego stanowiska pracy, ale także indywidualnych preferencji pracownika [SIKO2000]. Stosując aksjologiczne podejście, człowiek kształtuje i ocenia rzeczywistość zgodnie z przyjętym systemem wartości, a w konsekwencji paradygmat jakości [HAMA1998] polega na odnoszeniu wszystkich wytworów człowieka do jego systemu potrzeb, wartości, wymagań i celów.

Przy opracowaniu ankiety wykorzystano doświadczenia praktyczne, nabyte podczas ankiety przeprowadzonej wśród 44 studentów IV roku budownictwa korzystających z oprogramowania BW (Budynki Wysokie), pod kątem oceny jakości tego programu [BEG2002c]. Jej przedmiotem jest stosowane również poza uczelnią oprogramowanie wspomagające analizę statyczną i dynamiczną budynków wielokondygnacyjnych, usztywnionych konstrukcjami ścianowymi z nadprożami. Ankietę opracowano we współpracy z autorami programu BW, którzy otrzymali tą drogą wskazówki do dalszych prac nad oprogramowaniem dla inżynierów konstruktorów budownictwa. Wcześniej zdefiniowano wspólnie kryteria i miary oceny oprogramowania obliczeń inżynierskich [BEWD2001]. Główny nacisk położono na ocenę użyteczności oprogramowania, to jest interfejsu z użytkownikiem, łatwości obsługi programu, łatwości uczenia się tej obsługi oraz wydajności pracy użytkownika programu.

Oprogramowanie jest wyrobem rynkowym, a zatem przygotowując się do jego oceny wzorowano się częściowo na wytycznych zamieszczonych w podręcznikach marketingu [KĘKA1996, MPSS1999]. Przez ankietę rozumie się pomiar pośredni polegający na udzielaniu pisemnych odpowiedzi przez respondentów [Kacz2002]. Ankieta jest metodą pomiaru, a kwestionariusz ankietowy jego instrumentem. Kwestionariusz z pytaniami uznano za podstawowe narzędzie badania poziomu satysfakcji użytkownika z używanego oprogramowania. Przyjęto, że kwestionariusz powinien dostarczyć informacji nie tylko na temat cech oprogramowania, ale również w zakresie indywidualnych preferencji i odczuć. Najpierw opracowano ramowy kwestionariusz (wzorcowy) ankiety.Ankieta jest z założenia anonimowa. Na wzór innych kwestionariuszy, w tym zalecanych przez SEI do oceny dojrzałości procesów [ZUBR1994], część wstępna kwestionariusza obejmuje dane, które służą do poznania profilu użytkownika. W opracowanych ankietach pytano o:

• płeć,

• przedział wieku (18-28, 29-39, 40-50 i powyżej lat),

• poziom wykształcenia (wśród 7 możliwych opcji podano też „pomaturalne”),

• rodzaj wykształcenia (techniczne, humanistyczne, ekonomiczne, inne),

• ukończone kursy,

• znajomość języków obcych,

• zajmowane stanowisko służbowe,

• samoocena znajomości obsługi komputera: podstawowa, średnia, dobra, bardzo dobra,

• miejsce korzystania z komputera: tylko w pracy, w pracy i w domu, w innych miejscach,

• rodzaje wykorzystywanych narzędzi informatycznych,

• możliwość korzystania z pomocy bardziej doświadczonych osób w zakresie obsługi używanego oprogramowania,

• nazwy programów używanych w miejscu pracy.

Po ogólnym zapoznaniu się z badanym oprogramowaniem (na podstawie wywiadów z użytkownikami i administratorami oraz lektury udostępnionych dokumentów) opracowano zasadniczą część ramowego kwestionariusza ankietowego.

Za punkt wyjścia do budowy ankiety przyjęto sześć głównych atrybutów jakości oprogramowania, sugerowanych w ISO 9126-1:2001, których rolę i zakres znaczenia adaptowano do potrzeb badanych systemów. Na przykład, w ocenie funkcjonalności główny nacisk położono na dostępne funkcje zapewniające udogodnienia interfejsu z użytkownikiem, w tym usprawnienia we wprowadzaniu danych. Według standardu, ocena interfejsu należy lub częściowo nakłada się z oceną użyteczności. Z oceny funkcjonalności jako odrębną grupę wydzielono zagadnienia bezpieczeństwa, uważając je za jedne z ważniejszych aspektów systemów z bazami danych. Pytanie na temat autoryzacji dostępu do danych zaczerpnięto z dostępnej aktualnie w Internecie ankiety dotyczącej stopnia informatyzacji małych i średnich przedsiębiorstw [KOŁO2001].

Niezawodność ograniczono do szacowanej częstości występowania awarii, możliwości wycofania się z zaistniałej w danym kontekście sytuacji oraz zapewnianej pomocy w obsłudze sygnalizowanych błędów. Wydajność zaproponowano oceniać na podstawie czasu odpowiedzi systemu na wprowadzone polecenia łącznie z wymaganą transmisją danych, pracochłonności wprowadzania i weryfikacji danych, wzrostu zapotrzebowania na pamięć, ułatwień drukowania dokumentów, a w razie potrzeby wszystkich utrzymywanych informacji. Przenośność zawężono do ułatwień instalowania.

Ocena użyteczności obejmuje 13 pytań, które dotyczą w dużej mierze dostępności opcji systemu, łatwości poruszania się w systemie oraz zrozumiałości wyprowadzanych nazw, napisów, pozycji na listach wyboru, komunikatów. Oceniano łatwość obsługi, w tym prawidłowego określenia aktualnie używanej opcji systemu oraz szybkiego i bezproblemowego przechodzenia od jednej opcji do innej. Pytano o częstość sytuacji, w których konieczna jest pomoc w postaci korzystania z instrukcji użytkownika lub pomocy innych osób. Z założenia uznano, że odpowiedzi w tej grupie pytań mogą być obarczone sporą dozą subiektywizmu. Zupełnie subiektywne mogą być odpowiedzi w ostatniej grupie, w której pytania dotyczą komfortu lub dyskomfortu pracy, wpływu stosowania systemu na atmosferę w pracy, estetyki widoków systemu, lubienia posługiwania się ocenianym wyrobem.

Zawartość właściwej części kwestionariusza wzorcowego pogrupowano na osiem oznaczonych rzymskimi cyframi, podzestawów pytań o zróżnicowanej objętości. Podsumowując, przedmiotem ocen w zaprojektowanych grupach pytań są:

• Ogólna ocena systemu pod kątem faktycznego usprawnienia pracy w porównaniu z poprzednim trybem wykonywania powierzonych zadań,

• Funkcjonalność (współdziałanie z innymi systemami, stosowanie skrótów klawiszowych, brak spodziewanych funkcji, dostępność list wyboru, w tym list przewijanych pokazujących dane utrzymywane w pliku, podczas wprowadzania danych, możliwość dopasowania wyglądu ekranu do własnych potrzeb i upodobań, formaty wprowadzanych informacji, wygląd dokumentów, sposób identyfikacji dokumentów),

• Użyteczność,

• Bezpieczeństwo danych (10 pytań),

• Niezawodność,

• Wydajność,

• Przenośność (2 pytania),

• Odczucia.

Szczególną uwagę przywiązywano do języka kwestionariusza ankiety. Zawarte sformułowania konsultowano w kilkuosobowym zespole. Forma pytań nie określa płci osoby ankietowanej (gender-free language). Starannie zadbano o to, aby treść pytań nie sugerowała którejkolwiek odpowiedzi jako zalecanej, wyróżnionej, bądź mile widzianej.

Dysponując pytaniami wzorcowego kwestionariusza ankiety, zapoznano się bliżej z badanym oprogramowaniem poprzez obserwację pracy osób korzystających z ocenianych wyrobów. Poczynione spostrzeżenia posłużyły do rozbudowy ankiet o kilka pytań bezpośrednio wiążących się z charakterem badanego wyrobu. Pewną trudność sprawiał fakt, że każde używane oprogramowanie jest de facto zbiorem kilku niezależnych od siebie programów. W praktyce zdecydowano się na tworzenie kilku kwestionariuszy ankiet, odrębnie dla badanego podsystemu lub modułu. Niestety, dodatkowe pytania, uwzględniające specyfikę poszczególnych części badanego oprogramowania, praktycznie stają się mało użyteczne do wypracowania wspólnych wniosków końcowych. Całkowita objętość kwestionariusza każdej z opracowanych ankiet liczy 6 lub 7 stron tekstu.

Wszystkie pytania ponumerowano i umieszczono w tabelach. Grupa pytań jest opatrzona nagłówkiem, wydrukowanym wytłuszczoną czcionką. Każde pytanie zapisano w oddzielnym wierszu, z pozostawieniem w prawej kolumnie miejsca na odpowiedź. Linie poziome oddzielają dane pytanie i zestaw potencjalnych na nie odpowiedzi od kolejnych pozycji ankiety. Łącznie ankieta jest kilkustronicowym dokumentem. Od użytkowników nie oczekiwano pisania odpowiedzi tekstowych, szanując czas ich pracy oraz unikając zniechęcenia do wypełniania dostarczonych ankiet. W przeważającej liczbie przypadków odpowiedź na pytanie przybiera formę:

• zaznaczenia krzyżykiem wybranego elementu z listy wyboru,

• zakreślenia odpowiedzi „Tak” lub „Nie”,

• podania oceny według szkolnej skali od 1 do 5,

• czasami dopisania innej wartości lub dołączenia dodatkowych uwag.

Zarówno w części wstępnej, jak i zasadniczej, przy każdym pytaniu zamieszczono listę wyboru możliwych odpowiedzi, zostawiając w niektórych punktach miejsce zatytułowane „inne”. Przygotowane zestawy możliwych odpowiedzi miały z założenia uprościć późniejsze przetwarzanie wyników ankiety.

W wymienionych w rozdziale trzecim zakładach pracy uzyskano wyrażoną na piśmie zgodę kierownictwa na przeprowadzenie ankiety. Komendant straży pożarnej uznał pomysł ankiety wręcz za wskazany do realizacji i zażyczył sobie przekazania wyników. Pozostali przełożeni wykazali obojętność. Liczba ankietowanych:

• 15 pracowników szpitala w Wolsztynie (wśród nich 1 mężczyzna),

• 29 zatrudnionych w zakładach „Prefbet” w Powodowie (w tym 4 mężczyzn),

• 14 strażaków,

• 16 użytkowników programu InfoExpert.

Nie opracowano instrukcji wypełnienia kwestionariuszy ankiety, uznając ich treść za wystarczająco zrozumiałą (to stwierdzenie okazało się zbyt optymistyczne). Ponadto ankieterzy byli obecni na miejscu, mogąc w razie potrzeby służyć pomocą, ale trzymając się dyskretnie z boku, aby swym zachowaniem lub podpowiedziami nie wpływać na odpowiedzi.

Ankieta spotkała się ze zróżnicowanym przyjęciem ze strony pracowników. Niektórzy potraktowali ją życzliwie (szczególnie w Powodowie), część przyjęła wręcz niechętnie (głównie w szpitalu), a pozostali uznali ją za dodatkowy, neutralnie odebrany obowiązek. Większość respondentów była w pierwszej chwili „przerażona” objętością kwestionariusza.

Respondenci nigdy przedtem nie byli pytani o zdanie w sprawie jakichkolwiek cech wprowadzanego systemu informatycznego – potraktowano ich przedmiotowo w okresie zmiany trybu pracy związanego z przejściem na nowy system. Ankietowani pierwotnie sądzili, że to firma producenta przygotowała ankietę i liczyli na uwzględnienie wniosków z analizy ankiety. Koniec końców uznali ankietyzację za pożądaną i celową, aczkolwiek sens i wymiar praktyczny byłby lepszy, gdyby to organizacja dostawcy pospieszyła z ankietą. Okazało się też, że znajomość zaleceń norm ISO 9000, łącznie z postulowaną oceną poziomu satysfakcji użytkownika wyrobu, są lepsze wśród użytkowników oprogramowania aniżeli w gronie jego autorów.

Część kwestionariuszy ankietowani wypełnili w obecności ankietera. Udzielenie odpowiedzi na pytania zajęło od 20 do 45 minut. Niektórzy ankietowani nie zgodzili się odpowiadać w trybie natychmiastowym z uwagi na deklarowany nadmiar obowiązków. Tym osobom zostawiono kwestionariusze, po które ankieterzy zgłosili się, zgodnie z ustaleniem, po tygodniu. Wypełnione kwestionariusze ankiet oraz zaświadczenia o faktycznym przeprowadzeniu ankiet są w posiadaniu autorki artykułu.

Treść pytań i wartości udzielonych odpowiedzi zostały wpisane do arkuszy Excel, co ułatwiło dalsze prace. Na podstawie danych zawartych w arkuszach wygenerowano wykresy rozmaitego typu, głównie: kołowe, pierścieniowe, tortowe, zarówno dwu- jak też trójwymiarowe. Wykresy z kolei posłużyły do analizy danych i formułowania wniosków z poszczególnych ankiet z osobna oraz wspólnych dla wszystkich.

Ku pewnemu zaskoczeniu, rozrzut rezultatów poszczególnych ankiet przedstawia się podobnie. Z tego powodu, a także z uwagi na objętość artykułu, niektóre rezultaty zostaną podane łącznie. Ponadto autorka nie czuje się upoważniona do podania do wiadomości publicznej szczegółowych rezultatów dotyczących konkretnych miejsc pracy i użytkowanych tam systemów. Poniżej zestawiono zbiorcze dane, które nie powinny nikogo urazić, a których znajomość może przyczynić się do poprawy sytuacji.Interesujących danych dostarcza analiza profilu respondentów ankiety, którzy, jak się wydaje, reprezentują „Polskę powiatową”. Użytkownikami systemów informatycznych kategorii baz danych są w przeważającej mierze kobiety. Najliczniejszą grupę wśród ankietowanych (w szpitalu 46%) stanowią osoby w przedziale wieku 40-50 lat, również w Powodowie (15 osób). Ta struktura wiekowa odzwierciedla obecną sytuację w zakresie zatrudnienia. Wyjątek od tej reguły stanowią strażacy, którymi są sami mężczyźni, w 57% w przedziale 29-39 lat. Znajomość któregoś języka zachodniego deklaruje połowa strażaków, agentów ubezpieczeniowych oraz respondentów z Powodowa, a tylko jeden pracownik szpitala.

Wszyscy ankietowani mają przynajmniej średnie wykształcenie, ale już rzadko pełne wyższe. Większość korzysta z komputera tylko w pracy, a spośród ankietowanych pracowników szpitala nikt nie używa komputera w domu lub w jakimkolwiek innym miejscu poza pracą. Jedynie agenci ubezpieczeniowi w 62% korzystają z komputera również w domu.

Zastanawiające, że większość respondentów deklaruje znajomość posługiwania się komputerem i systemem jako dobrą lub bardzo dobrą (rysunek 1). Przy tym pewne zdziwienie wzbudza fakt, że spora grupa respondentów nie zna wymaganych pojęć informatycznych, na przykład: interfejs, arkusz kalkulacyjny (niektórzy ankietowani nie łączyli nazwy Excel z arkuszem kalkulacyjnym), moduł, komponent, odporność na błędy, logika funkcji, a nawet przeglądarka internetowa. Z drugiej strony nikt nie przyznał się do korzystania z instrukcji użytkownika! Respondenci a priori uznali ją za zbyt trudną i nieprzydatną. Nieświadomość powyższych faktów spowodowała, że wymienione przykładowe terminy znalazły się w treści pytań kwestionariuszy. Wnioski powinni wyciągnąć nie tylko autorzy kwestionariuszy przyszłych ankiet, ale również osoby odpowiedzialne za szkolenia, nauczyciele podstaw informatyki, a także projektanci widoków obiektów aplikacji oraz autorzy instrukcji użytkownika. Około jedna trzecia badanych przyznała, że czasami nie rozumie treści wyprowadzanych komunikatów o błędach lub innych zdarzeniach. Można odnieść wrażenie, że program prowadzanych obecnie szkoleń ogranicza się wyłącznie do klikania myszą i stukania w klawiaturę.

Zgłaszane przeciążenie pracą wydaje się charakterystyczne w obecnych czasach i rzutuje na sposób korzystania z systemu informatycznego. Otóż niemała część ankietowanych przyznała, że występują znaczne opóźnienia, czasami sięgające nawet kilku miesięcy, we wprowadzaniu danych do systemu! W szpitalu blisko 60 % przyznało się do opóźnień we wprowadzaniu danych, w Powodowie 50%. Może to podważać wartość stosowania środków informatyki. Ankietowanym zdarza się szukać w systemie danych, które jak się później okazuje, nie zostały jeszcze wprowadzone (rysunek 2). Częściowym rozwiązaniem byłoby udostępnienie podczas wprowadzania danych w większym niż dotąd stopniu rozmaitych list przewijanych itp., a nie zmuszanie pracowników do wpisywania większości danych z klawiatury. Wniosek powinien być adresowany także do nauczycieli akademickich, którzy zbyt mało uwagi poświęcają tak prozaicznym sprawom, jak usprawnienie wprowadzania danych. Ankietowani zgłaszali, że szkolenie powinno obejmować naukę szybkiego pisania z klawiatury, a najlepiej, gdyby było poprzedzone nauką obsługi programu EXCEL.

Niezwykle duży rozrzut odpowiedzi wystąpił w pytaniu o udział procentowy czynności zawodowych wykonywanych z wykorzystaniem komputera – w szpitalu od 1% do 90%, w Powodowie deklarowano od 4,5 do 100%. Wydaje się, że ankietowani nie zrozumieli pytania lub nie czuli się kompetentni do udzielenia na nie odpowiedzi. Jednocześnie przytłaczająca większość odpowiadała „Nie” na pytanie, czy w systemie brakuje funkcji, która warto by dołączyć podczas ewentualnej rozbudowy systemu.Podobny rozrzut dotyczy pytania, czy wprowadzenie systemu spowodowało zmianę technologii pracy. Wydaje się, że pracowników nikt nie zapoznaje z pojęciem technologii pracy, a stosowanie określonych funkcji traktują po prostu jako kolejny obowiązek. Respondenci nie znają możliwości nowoczesnych systemów informatycznych. Na przykład, dopiero z treści kwestionariusza dowiadywali się, że poszczególne systemy mogłyby wymieniać dane między sobą.

Wysokie noty uzyskała łatwość obsługi, kompletność funkcji, sposób identyfikacji dokumentów (wyjątek u strażaków), wygląd generowanych dokumentów, łatwość poruszania się po programie. Wśród agentów ubezpieczeniowych 87% osób wyraża się pozytywnie o obecnym systemie. Duży rozrzut pojawił się w pytaniu o liczbę dni potrzebnych na naukę obsługi systemu: od 2 do 14 dni. Ocena łatwości nauczenia się obsługi systemu szła w parze z deklarowaną liczbą dni koniecznych na naukę.

Najbardziej żałośnie przedstawia się kwestia dbałości o bezpieczeństwo danych. Otóż 72% ankietowanych podaje, że w ich organizacji nie jest stosowany system haseł dostępu do danych (rysunek 3) lub hasła są zmieniane nie częściej niż raz na pół roku. Jednocześnie 64% deklaruje, że system w wystarczający sposób chroni przechowywane dane. Jedna trzecia uważa, że są wykonywane kopie bezpieczeństwa, a pozostali, że nie. Wydaje się, że świadomość zagrożeń wynikających z braku lub lekceważenia ochrony danych jest żenująco niska.

Podsumowując, poziom satysfakcji użytkowników można ocenić jako dobry. Pocieszający niech będzie fakt, że respondenci zasadniczo lubią korzystać z systemu. Większość z nich uważa, że stosowanie systemu dobrze wpływa na atmosferę w pracy (rysunek 4).

Być może korzystanie ze środków informatyki stanowi rodzaj nobilitacji zawodowej. W Powodowie aż 26 na 29 osób stwierdziło, że preferuje pracę z obecnym systemem w porównaniu z poprzednią technologią pracy.

Inżynierowie oprogramowana wykazują wiedzę i wkładają wiele wysiłku zastanawiając się, jak zbudować dany system, tymczasem w pierwszej kolejności należałoby poświęcić sporo uwagi kwestii, czy cel tworzonego systemu jest słuszny ze społecznego punktu widzenia. W odróżnieniu od opisanych w poprzednich sekcjach cech, badanych drogą ankietyzacji wyrobu programowego, aspekty etyczne i społeczne planowanego systemu informatycznego powinny być przedmiotem oceny przed rozpoczęciem prac.Celem większości systemów informatycznych jest zwiększenie efektywności i wydajności pracy w danej organizacji, czyli cięcie kosztów. Interes danej firmy nie musi pokrywać się z interesem społecznym, zwłaszcza, jeśli owocuje na przykład: umożliwieniem nieetycznych zachowań, ignorowaniem ogólnoludzkich wartości, rosnącym bezrobociem, postępem w zakresie tzw. macdonaldyzacji społeczeństwa oraz zrywaniem więzi między ludźmi, zarówno w efekcie długotrwałego przesiadywania przed ekranem monitora, jak i obawą o utratę pracy spowodowaną ostrą konkurencją na rynku pracy. Innymi słowy, pozornie korzystne efekty krótkoterminowe mogą okazać niesłuszne, a nawet zgubne w dłuższej perspektywie. Stąd wniosek, aby zwrócić uwagę na jakość celów [BEG-2002a].

Przykłady nieetycznych zachowań w obszarze IT obejmują: przejmowanie cudzych pomysłów i projektów, kradzież informacji, przedkładanie plagiatów, złośliwe usuwanie dokumentów, handel danymi, zarzucanie niechcianą informacją, zamieszczanie informacji obraźliwych, celowe przeciążanie serwerów, „kreatywna” księgowość. Przy takich zagrożeniach pojawia się na wyrost utrata zaufania do pracowników i faktyczna nielojalność niektórych z nich. Automatyzacja prac biurowych powoduje, że praca niegdyś umysłowa staje się powtarzalna aż do znudzenia, podobnie jak się to stało w latach trzydziestych z pracą fizyczną po wprowadzeniu taśmy produkcyjnej. W efekcie, kto mógł, ten unikał takiej pracy. Tworzenie dla kogoś takiego rodzaju pracy, której samemu nie chciałoby się nigdy wykonywać, zaliczam także do nieetycznych zachowań.

Podobnie marnotrawstwo publicznych funduszy podczas budowy dużych systemów informatycznych o zasięgu krajowym występuje niemal w każdym kraju. Do często spotykanych błędów w kontraktach publicznych na oprogramowanie zalicza się:

• Deklarowane wirtualne koszty, tj. takie, które pozwolą wygrać przetarg,

• Nierealny termin dostawy,

• Nieprawidłowy harmonogram etapów,

• Świadomie niekompletne wymagania,

• Brak doświadczenia dostawcy w danej dziedzinie zastosowań,

• Długi okres wyczekiwania na poprawę zgłaszanych defektów,

• Brak alternatywnych procedur na wypadek niepowodzenia przedsięwzięcia programowego,

• Niewystarczająca troska o walidację danych.

Jak dotąd, podejmowane są nieśmiałe próby przeciwdziałania informatycznemu lobby i ujawniania marnotrawstwa pieniędzy podatników poprzez działalność publikacyjną i informowanie parlamentarzystów o możliwościach uzdrowienia sytuacji drogą zmiany regulacji prawnych w dziedzinie ogłaszania, rozstrzygania, monitorowania i rozliczania zamówień publicznych na systemy informatyczne o zasięgu ogólnokrajowym [ERSK-2000]. Proponuje się poprzedzić analizę wymagań zgłoszonych dostawcy analizą etyczną wraz z analizą przewidywalnych skutków społecznych przedsięwzięcia podejmowanego za środków publicznych [BEG2002b]. Przedmiotem analizy etycznej mogą być:

• Respektowanie prywatności,

• Zachowanie prawa własności,

• Sprawiedliwy dostęp do zasobów,

• Unikanie przemocy (także ekonomicznej),

• Potencjalne źródła ryzyka,

• Aspekty uczciwości i potencjalnie ułatwionego oszustwa,

• Poprawa jakości pracy i życia,

• Poszanowanie wielokulturowości.

Każdy z wymienionych wyżej elementów listy zasługuje na temat odrębnego referatu.

W rozdziale uzasadniono potrzebę pomiaru satysfakcji użytkownika ze stosowanego wyrobu programowego. Uznano, że poziom satysfakcji jest pochodną jakości oprogramowania. Przedstawiono źródła inspiracji i pomysłów podczas konstruowania kwestionariusza oceny jakości oprogramowania. Ankiety dotyczące czterech różnych programów przeprowadzono w rzeczywistych zakładach pracy. Trudno określić, w jakim stopniu respondenci stanowili reprezentatywną grupę pracowników. Nie są to wielkie organizacje i można przyjąć, że dobrano odpowiednią do zamierzeń grupę respondentów.Wydaje się, że przedmiot oceny potraktowano zbyt szeroko, poświęcając w efekcie zbyt mało uwagi aspektom etycznym i społecznym. Zwrócono jednak uwagę na tę stronę oceny. Ankietowani nie pochwalali dużej objętości kwestionariuszy i być może odpowiadali na niektóre pytania bez głębszego zastanowienia. Rezultaty ankiet zebrano w rozdziale szóstym.

Sugeruje się upowszechnić praktykę ankietyzacji wyrobów programowych w szerokim gronie jego użytkowników. Z jednej strony analitycy i projektanci programiści mogą tą drogą poznać profil przygotowania zawodowego i informatycznego użytkowników tworzonego systemu – nawet, jeśli wnioski z ankietyzacji nie okażą się budujące. Ankieta w wielu punktach obnażyła istniejącą rzeczywistość, w tym poziom edukacji. Z drugiej strony, od lat mówi się o zbyt trudnym języku używanym przez informatyków i wynikających stąd barierach komunikacyjnych, ale nie widać wyciągania z tego praktycznych wniosków.

Proponuje się, aby ankietyzacja była elementem pętli jakości, to jest występowała w modelu ewolucyjnym cyklu w pętli sprzężenia zwrotnego po każdym wdrożonym przyroście tworzonego systemu. Odpowiedzi na pytania pozwoliłyby wcześnie zmienić niektóre rozwiązania, na przykład w zakresie sposobu wprowadzania danych oraz ich ochrony. Ponadto pracownicy mogliby odnieść cenne wrażenie, że mają wpływ na formę wprowadzanego systemu, a tym samym wdrażaną technologię pracy. Kwestionariusze ankiet pozwoliłyby także wychwycić komunikaty, które są niezrozumiałe dla części użytkowników.

Nie zdołano zachować proporcji między oceną poszczególnych aspektów jakości oprogramowania, niemniej włączono do ankiety rozmaite cechy wyrobu i jego wpływu na przebieg pracy. W kontekście ogólnoludzkim dostrzega się pewien konflikt między deklarowaną dbałością o rozwój najpierw ucznia, studenta, później pracownika, a następnie wtłaczaniem go w ustalone odgórnie tryby pracy, bez zapewnienia wpływu na jej formy. Wydaje się, że tzw. czynnik ludzki będzie jednak w dłuższej perspektywie zyskiwał na znaczeniu. Proponuje się rozwijać prace w zakresie szeroko traktowanej oceny jakości wyrobów programowych przez ich użytkowników.