Witajcie!
bardzo dziękuję Organizatorom Pierwszej Konferencji SASO "Inżynieria Jakości Oprogramowania", za znakomitą przygotowanie całości tego ważnego Wydarzenia. Szczególne zaś podziękowania należą się Im, za rozpoczęcie, tym Spotkaniem, cyklicznych, otwartych dyskusji Fachowców, zebranych wokół Jakości i Standaryzacji Oprogramowania. Czyli takiej formie oprogramowania, która będzie użyteczna dla Użytkownika końcowego.
W tym miejscu pragnę wyrazić swoją własną opinię i wskazać, zwłaszcza Osobom nie będącym świadkami Konferencji, na ważne różnice znaczeniowe w dziedzinie Informatyka. W mojej opinii pozwolą one spoglądać na zagadnienia naszych prac, ze zrozumieniem ich intencji.
Otóż, w różnych dyskusjach, zagadnienie Inżynierii Jakości Oprogramowania (skrót IJO) jako dziedzina nauki i technologii, nie znajduje zrozumienia w aspekcie dobrze zadomowianej Inżynierii Oprogramowania (skrót IO). W tym przypadku pragnę zwrócić uwagę na wzajemne nakładanie się, ale nie wykluczanie i wchłanianie, obszarów zainteresowań obu dziedzin. W mojej opinii, opartej na analizie paradygmatów nauki, w tym oczywiście Informatyki i tematów poruszanych na Konferencji, Inżynieria Oprogramowania skupia się na poprawnym informatycznie wyspecyfikowaniu, zaprojektowaniu, zaimplementowaniu, zintegrowaniu wytwarzanego oprogramowania, jego rozwoju oraz zapewnienia ciągłości jego życia (ogólnie rozumianej aktualizacji). I o ile w tym przypadku, jakość oprogramowania jest podmiotem poprawności algorytmicznej oraz odpowiedniej implementacji, o tyle, w przypadku Inżynierii Jakości Oprogramowania, istotne jest takie ustandaryzowanie podejścia do programowania, a zwłaszcza Interfejsów Użytkownika (obecnie głównie Graficznych – GUI), aby jakość oprogramowania z punktu widzenia użyteczności i ergonomii pracy była dla Użytkownika najwyższa. Jest to właściwie stwierdzenie oczywiste. Jednak należy zwrócić uwagę, że mimo, iż Klient chciałby, aby jakość (w sensie ogólnym IO / IJO) była „najwyższa”, to ze względu na koszt, wytworzenie takiego wysokojakościowego produktu nie jest możliwe – kwestia dostępnego czasu na poprawki, często „kosmetyczne” i środków finansowych, na utrzymanie Personelu informatycznego. Dlatego, przy silnym nacisku na jakość w IO, często nie starcza już czasu i funduszy na jakość z punktu widzenia Użytkownika. Tym bardziej, że często Klient (zamawiający i płacący), rzadko jest później Użytkownikiem tej aplikacji.
Właśnie dlatego, niezależnie od jakości z punktu widzenia IO, konieczne jest rozwijanie standardów z punktu widzenia Użytkownika końcowego (wg IJO). Wdrożenie takich standardów pozwoli z automatu na udział w procesie tworzenia Interfejsu Użytkownika właśnie Użytkownika końcowego oprogramowania/systemu. Zapewne z punktu widzenia Producenta aplikacji, skomplikuje to i podroży proces zapewniania inżynieryjnej jakości oprogramowania, jednak dzięki standaryzacji działań, nie powinno to podnosić kosztów tworzenia oprogramowania. Stwierdzenie to może wyglądać nieco kuriozalnie, jednak jak najbardziej dokładna standaryzacja wymagań – nazwanie ich, pogrupowanie i zaszufladkowanie do odpowiednich działań aplikacji, na pewno wpłynie pozytywnie na proces projektowania, programowania i wdrażania systemu. Po pewnym czasie wymagania spisane w kontakcie z Użytkownikiem i utrwalone w standardach, wdrożone w wielu aplikacjach, tak przylgną do codziennej pracy Użytkowników, że każda kolejna aplikacja będzie wymagała coraz mniej indywidualnych poprawek, zgłaszanych przez Użytkownika, potrzebnych do codziennej, ergonomicznej pracy.
Jednocześnie jestem pewien, że wzajemne zrozumienie poruszanych zagadnień, nie będzie wywoływać kontrowersji w „konkurencyjnych” działaniach Inżynierów Jakości, w ten sposób stanowiąc postęp w dziedzinie Informatyka i jej pokrewnych.
serdecznie pozdrawiam
Zbigniew Chaniecki