Czym jest jakość oprogramowania

Transkrypt

1 Czym jest jakość oprogramowania Radosław Hofman, EUR ING Abstrakt. Niniejszy artykuł przedstawia rozważania na temat definicji jakości oprogramowania odwołując się do historycznych publikacji oraz najnowszego modelu ISO/IEC JTC1/SC7. Dodatkowo w artykule znajdują się rozważania na temat postrzegania jakości przez użytkownika oraz ich ewaluacja. Na zakończenie autor przedstawia podsumowanie prezentujące różne spojrzenia na jakość oprogramowania oraz wstęp do dyskusji o potrzebie definiowania standardów rynkowych dla jakości oprogramowania, oraz cech przyszłych modeli jakości. 1. Wprowadzenie Produkty IT zwane potocznie oprogramowaniem zostały zdefiniowane i wyodrębnione spośród innych produktów w drugiej połowie XXw. Produkty te odróżniają się od większości obiektów wytwarzanych wcześniej przez człowieka z jednej strony są niematerialne, a z drugiej działają jako narzędzia w rzeczywistym i materialnym świecie. Z wytwarzaniem produktów od zawsze związane było pojęcie jakości produktu. Nie można dziś zbadać dokonań człowieka w zakresie porównywania jakości narzędzi i przedmiotów w epokach kamienia łupanego i kolejnych, jednakże pierwsze wzmianki o ocenie jakości płótna lnianego przypisywane są Egipcjanom, a datowane na XXI w.p.n.e.. Z kolei w kodeksie Hammurabiego z XVIII-XVII w.p.n.e. znajdujemy wzmianki o odpowiedzialności szkutnika i budowniczego w przypadku produktu o złej jakości [Kili1979]. W starożytnym Rzymie nazwano zasadę Caveat emptor, która w istocie jest również uregulowaniem problematyki jakości nabywanego produktu. 1 Analizując spojrzenie na jakość panujące już w czasach starożytnych należy wspomnieć o pismach Arystotelesa, który to postrzegał jakość jako jedną z 10 tzw. Kategorii. Jakość wg. tego filozofa to zbiór cech odróżniających rzecz od innych tego samego typu [Aryst1999]. W czasach średniowiecz pojawiła się po raz pierwszy udokumentowana rola zawodowa, którą dziś nazwanoby kontrolerem jakości na przełomie XII i XIII w. Jan, król Anglii zatrudnił niezależnego eksperta Williama Wrotham aby w jego imieniu sprawował kontrolę nad produkowanymi na zamówienia króla statkami. W czasach nowożytnych problematyka jakości i kontroli jakości opisana jest niemalże wyczerpująco. Powstały różne podejścia do zapewnienia i kontroli jakości opisane zarówno w standardach ISO, normach krajowych jak i publikacjach z zakresu SPC (Statistical Process Control), SQC (Statistical Quality Control), TQM (Total Quality Management), Six Sigma itd. Podejścia te opisują metody planowania procesów zapewniających możliwość produkcji wysokiej jakości produktów oraz metody 1 łac. niech kupujący strzeże się

2 Czym jest jakość oprogramowania 2 kontroli jakości procesów i produktów. Metody te są bardzo powszechnie implementowane w przemyśle, a funkcjonujące automatyczne linie produkcyjne wyposażane są w stanowiska automatycznej kontroli jakości. Tematyka jakości jest na tyle dynamiczną dziedziną, że spowodowała powstanie nowej dyscypliny badawczej kwalitologii [HamMan2002]. Kwalitologia jest interdyscyplinarnym obszarem badań pomiędzy teorią jakości a inżynierią jakości obejmującą kwalimetrię, zarządzanie jakością i ekonomikę jakości [Jag2004]. Czym jest jakość w odniesieniu do jakiegoś obiektu? Większość definicji w literaturze odnosi jakość do konkretnego modelu lub obszaru stosowalności obiektu, dla jakiego jakości jest definiowana. Jakość można zatem zdefiniować jako zdolność obiektu do spełnienia zdefiniowanych i dorozumianych potrzeb w określonym kontekście użycia. Definicja ta jest bardzo szeroka, stąd też pozostawia duże pole do analizy znaczeniowej. Takie definicje jakości pojawiają się zarówno w normach ISO [ISO/IEC 9126:2001, ISO/IEC 25000] oraz literaturze [Kili1979]. W przypadku oprogramowania komputerowego, które jak wspomniano powyżej, różni się znacząco od innych produktów wytwarzanych przez człowieka sytuacja z jednej strony jest analogiczna do innych produktów, a z innej perspektywy zupełnie inna. Po pierwsze oprogramowanie jest bytem niematerialnym. Jako taki byt posiada szereg cech statycznych i dynamicznych. W odróżnieniu od innych produktów, w przypadku oprogramowania cechy statyczne są niemalże pomijalne w aspekcie jakości oprogramowania. Z punktu widzenia użytkownika można powiedzieć, że oprogramowanie tak samo jak inne produkty posiada określoną zdolność do zaspokajania potrzeb użytkownika, co czyni je produktem o podobnych właściwościach do innych produktów. Proces wytwarzania oprogramowania w sposób zasadniczy różni się od sposobu wytwarzania produktów materialnych. Co za tym idzie, proces zapewnienia i kontroli jakości oprogramowania różni się istotnie od procesów zapewnienia i kontroli jakości innych produktów. Główna różnica polega na powtarzalności zadań w przypadku wytwarzania oprogramowania mamy do czynienia z fazą analogiczną do wytwarzania prototypu przedmiotu przemysłowego (nowa analiza, nowy projekt, nowe wykonanie), gdy tymczasem przytoczone wcześniej podejścia i normy określają zasady zapewnienia i kontroli jakości w powtarzalnych czynnościach. Pierwsze wzmianki o zapewnianiu jakości pojawiły się w publikacjach dotyczących Inżynierii Oprogramowania pojawiają się w literaturze lat 1960, gdzie IBM oraz Departament Obrony USA zdefiniowały po raz pierwszy takie pojęcie [Voa2003]. Od tamtej pory zdefiniowano wiele modeli

3 Czym jest jakość oprogramowania 3 jakości oprogramowania, a najważniejsze z nich zostaną omówione w rozdziale. W chwili obecnej trwają prace nad modelem SQuaRE, który wyrażany jest w normach ISO/IEC W wielu pozycjach w literaturze jakość oprogramowania jest wiązana z jakością procesu wytwarzania oprogramowania, choć są i takie pozycje które wyraźnie zaznaczają, że jakość procesu nie ma wpływu na jakość produktu [Dromey1996, KitPfle1996]. Trzecim istotnym punktem widzenia jest relacja dojrzałości organizacji i jakości produktów związek taki jest prezentowany w samym modelu CMMI oraz [Eic2003, DiaSli1997]. Wszystko o czym wspomniano do tej pory w tym artykule dotyczy inżynierskich definicji, pojęć i formuł. Czy takie pojęcia pozwalają na ostateczne zdefiniowanie sposobu postrzegania jakości oprogramowania przez Klienta i użytkownika? Czy da się zwymiarować potrzeby odbiorców, w taki sposób aby jednoznacznie obliczyć poziom ich zaspokojenia? A może same potrzeby są niejednorodne i mają wiele niezbadanych cech skazując wszystkie modele na oderwanie od rzeczywistości. W niniejszym artykule, w rozdziale znajduje się zalążek rozważań na ten temat, jednakże należy się spodziewać jego intensywnej eksploracji w najbliższych latach. Abstrahując od sposobu wytwarzania oprogramowania i subiektywizmu wynikającego z odczuć odbiorcy oprogramowania można podjąć próbę zdefiniowania standardów jakości dla oprogramowania prezentując różne punkty widzenia, co zostanie przedstawione w rozdziale. Dodatkową motywacją do zdefiniowania lub odnowienia modelu jest fakt zmiany sposobu korzystania z oprogramowania. Dziś zamiast oprogramowania coraz częściej mówi się o kompozycie usług świadczonych drogą elektroniczną, a co za tym idzie, kryteria jakości takie jak: łatwość instalacji, koszt utrzymania itp. nie mają jakiegokolwiek zastosowania, z kolei pojawiają się nowe obszary definiujące użyteczność, czy jakość takiej usługi. 2. Modele jakości 2.1. Historyczne modele jakości McCall 1977 i Boehm 1978 Jedynymi z pierwszych modeli w literaturze są modele McCall z 1977 roku [McCa1977] i Boehm z 1978 roku [Boe1978, Pfle2001]. Model McCall, postrzegany jako ogólna koncepcja trudna do zastosowania w praktyce, wprowadza zestaw oczekiwanych charakterystyk jakości, oraz pokazuje zestaw atrybutów/metryk, które na ową jakość mają wpływ. Model ten koncentruje się na cechach technicznych produktu.

4 Czym jest jakość oprogramowania 4 Model Boehm zmienia punkt widzenia jakości oprogramowania przenosząc punkt ciężkości na perspektywę użyteczności oprogramowania. Według [Pfle2001] jest to pierwsze wskazanie, że jakość oprogramowania może być postrzegana tylko wtedy, kiedy oprogramowanie jest użyteczne ISO 9126:1991 Standard ten miał definiować charakterystyki jakości oraz być przewodnikiem dotyczącym sposobu ich oceny. Dosyć szybko model opisany w tej normie stał się wyznacznikiem sposobu definiowania jakości oprogramowania [BAJ1993]. Model opisany w normie określał 6 głównych charakterystyk jakości: funkcjonalność (functionality), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintanability), przenośność (portability). Norma nie spełniła pokładanych w niej nadziej [Pfle2001], głównie ze względu na ograniczenie się do perspektywy producenta, brak stanowiska w sprawie całościowej oceny jakości oraz brak dokładnych wytycznych jak należy mierzyć poszczególne parametry jakości Kitchenham & Pfleeger 1996 W swojej publikacji [KitPfle1996] autorzy nie definiowali nowego modelu jakości, ale podsumowali spojrzenia na jakość i ich ewolucję wyróżniając pięć różnych perspektyw: jakość jako pojęcie metafizyczne, nieosiągalny ideał do którego zmierzamy jakość z punktu widzenia użytkownika jako odniesienie cech produktu do interesującego użytkownika kontekstu użycia jakość z punktu widzenia producenta jako zgodność z wymaganiami (analogiczny do spojrzenia ISO 9001:1994 jakość jako atrybut produktu wynikająca z konkretnych wyników pomiaru charakterystyk produktu ostatecznie jakość postrzegana jako wartość różna dla różnych grup interesariuszy Autorzy podkreślali również, że jakość produktu jest zjawiskiem niezależnym od jakości samego procesu wytwórczego ISO/IEC 9126:2001 Norma ISO/IEC 9126 z 2001 roku w sposób istotny zmieniła rozumienie modelu jakości oprogramowania zaprezentowane w jej poprzednim wydaniu. Norma rozróżnia trzy poziomy jakości i co za tym idzie definiuje 3 zbiory charakterystyk: jakość wewnętrzna/statyczna (internal quality) jakość zewnętrzna/dynamiczna (external quality) jakość użyteczna (in use quality)

5 Czym jest jakość oprogramowania 5 Model zdefiniowany w normie pokazuje również różne aspekty jakości dyskutowane we wcześniejszych modelach, czyli jakość produktu, jakość techniczną produktu, a jakość procesu, tak jak to widać na rysunku. Process Software products Effect of software product Influences Influences Influences Process quality Internal quality attributes External quality attributes Depends on Depends on Depends on Quality in use attributes Contexts of use Process measures Internal measures External measures Quality in use measures Rys. Jakość w cyklu życia systemu [ISO/IEC 9126:2001] Każdy z tych obszarów ma odmienne znaczenie i odmiennego interesariusza. Wewnętrzna i zewnętrzna jakość definiowana jest jako suma następujących charakterystyk (analogicznych do poprzedniego wydania normy 9126): funkcjonalność (functionality), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintainability), przenośność (portability). Jakość użyteczna definiowana jest jako suma następujących charakterystyk: przydatność (effectiveness), produktywność (productivity), bezpieczeństwo (safety) i zdolność do zaspokojenia potrzeb (satisfaction) ISO/IEC 25000:2005 Model nazywany Drugą Generacją Standardów Jakości - SQuaRE (Software product Quality Requirements and Evaluation) [SurAbr2003] publikowany w serii norm ISO/IEC Zestaw norm nie tylko porządkuje model oceny jakości oprogramowania opisany w ISO/IEC 9126:2001, model procesu ewaluacji oprogramowania opisany w ISO/IEC 14598, ale w sposób istotny go rozszerza. Na najwyższym poziomie modelu jakości oprogramowania pozostawiono podział na jakość wewnętrzną, zewnętrzną i użyteczną. Jakość wewnętrzna i zewnętrzna oprogramowania zdefiniowana jest analogicznie do definicji w ISO/IEC 9126:2001, z tym że zmieniono charakterystyki wysokiego poziomu zamiast sześciu w nowym modelu jest osiem: funkcjonalność (functionality), poufność

6 Czym jest jakość oprogramowania 6 (security), zgodność techniczna (interoperability), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintainability) i przenośność (portability). Jakość użyteczna oprogramowania, została zdefiniowana na nowo w modelu SQuaRE. Jej główne charakterystyki to: użyteczność (usability in use), zgodność z kontekstem (context in use), bezpieczeństwo (safety in use), poufność (security in use) i łatwość użycia (adaptability in use). Modele jakości SQuaRE opisują zarówno oprogramowanie, jak i dane. Twórcy normy zauważają, że nie są to jedyne modele jakości dla bytu nazywanego systemem, lecz norma odnosi się tylko do wspomnianych modeli. Na rysunkach i pokazano mapowanie modeli jakości SQuaRE na model systemu, oraz cykl życia jakości w ramach rozwoju produktu jakim jest oprogramowanie. QUALITY MODELS Internal software quality External software quality Software impact on system quality in use Software quality model Data quality model Quality in use model System Information system Computer system n Computer system 1 Commun -ication Human business process Mechanical system Computer hardware Other software Target software Other data Target data Users Rys Odniesienie modeli SQuaRE do jakości elementów systemu [ISO/IEC CD]

7 Czym jest jakość oprogramowania 7 REQUIREMENTS PRODUCT Needs User quality needs Quality in use Use and feedback Contribute to specyfying Indicates External quality requirements Contribute to specyfying Validation and verification External quailty Indicates Internal quality requirements Verification Internal quality Implementation Rys. Cykl życia jakości produktu jakim jest oprogramowanie [ISO/IEC CD] 2.2. Literatura w Polsce W literaturze dostępnej w Polsce bardzo często jakość produktu utożsamiana jest z jakością procesu, w którym produkt ten powstaje. W [Beg1999] autorka wręcz stwierdza się, że nie można mówić o jakości produktu, jeżeli nie mówi się o jakości procesów. W innych pozycjach, np. [Jasz1997] autorzy proponują własne charakterystyki jakościowe dla oprogramowania. W wydanych tego samego roku zasadach organizacji projektowania, wdrażania i eksploatacji systemów informatycznych w Resorcie Obrony Narodowej [MON1999] o aspektach jakościowych wymagań dla systemów praktycznie nie ma wzmianki. Autorzy zaznaczają jednakże, że podstawowym wymaganiem dla systemu jest potwierdzenie jego bezpieczeństwa w aspektach poufności, integralności i dostępności danych. Podstawą odbioru i oceny systemu, którą to można rozumieć jako ocenę jakościową, jest całość rozwiązania rozumianego jako aspekty informacyjne, funkcjonalne, organizacyjne, technologiczne i techniczne. Inaczej mówiąc dla systemów realizowanych na potrzeby obronności kluczowym nie jest charakterystyka systemu jako takiego, ale charakterystyka systemu i jego otoczenia umieszczonego w konkretnym środowisku oraz przydatność

8 Czym jest jakość oprogramowania 8 i efektywność tak przygotowanego systemu. Pomimo, że w czasie kiedy dokument powstawał obowiązująca postać normy ISO 9126:1991 koncentrowała się na aspektach technicznych oprogramowania, to ich postrzeganie jakości jest zbieżne z obecnym rozumieniem prezentowanym w ISO/IEC (patrz rys. ). W publikacjach [Beg2003], [Koby2003] i [Koby2005] autorzy opisuje nową wersję normy ISO/IEC 9126:2001, podkreślając jednocześnie rozróżnienie pomiędzy jakością wewnętrzną i zewnętrzną, rozumianą jako jakość techniczną obiektywnie mierzalną, od jakości użytecznej, która jest subiektywnym postrzeganiem przez użytkownika jakości produktu, jednakże główną uwagę poświęcają aspektom technicznym oprogramowania (czyli wynikającym z poprzedniej wersji normy). W pracy doktorskiej z 2000 roku [Dymek2000] autor zauważa rozdźwięk pomiędzy jakością techniczną i marketingową oprogramowania. Jakość techniczna to według autora głównie jakość wykonania, a jakość marketingowa to jakość postrzegana przez klienta (profil sensoryczny). Autor wspomnianej pracy dodatkowo wprowadza kilka klas aktorów zaznaczając, że ich postrzeganie jakości i oczekiwania są różne. W stosunku do proponowanego w niniejszej pracy zestawu autor dzieli użytkowników na 3 grupy: pracowników merytorycznych, pracowników IT, kierowników niższego szczebla. Dodatkowo autor podaje przykład na zmienność postrzegania jakości w czasie argumentując, że w pierwszej fazie eksploatacji dla użytkownika kluczowa jest łatwość uczenia się oprogramowania, a po jego dobrym Poznaniu kluczowa staje się przeciwstawna według autora cecha czyli bogactwo funkcji. W [Koby2005] autor również podkreśla, że spojrzenie na jakość ewoluuje w czasie trwania projektu, który rozpoczyna się zazwyczaj obustronnym spojrzeniem na jakość jako jakość idealną do punktów widzenia jakości ukierunkowanej na użytkownika po stronie odbiorcy oprogramowania oraz jakość ukierunkowaną na wytwórcę po stronie dostawcy. W pracy pojawiają się zatem perspektywy użytkownika, klienta, dostawcy, programisty i osoby odpowiedzialnej za utrzymanie oprogramowania Standardy dla procesu kontroli jakości Jako, że głównym tematem artykułu jest jakość produktu możnaby zupełnie pominąć kwestię standardów dla procesu wytwarzania i kontroli jakości. Niemniej jednak dla kompletności obrazu należy wspomnieć, że takie standardy również istnieją i opisane są w odpowiednich normach. W aspekcie kontroli jakości standardy były opisane zarówno w ISO 9126:1991, następnie w ISO/IEC 14598:1998, a obecnie stały się częścią modelu SQuaRE i są opisane w normie ISO/IEC Norma nakłada na proces ewaluacji następujące wymagania:

9 Czym jest jakość oprogramowania 9 należy określić cele ewaluacji należy określić mierzone charakterystyki i oczekiwane miary należy dobrać metody i narzędzia dające wiarygodny pomiar charakterystyk jakościowych należy wykonać ewaluację zgodnie z planem po wykonaniu ewaluacji należy zagregować wartości pomiarów i zweryfikować z założonymi wcześniej wartościami 2.4. Podsumowanie modeli jakości Jak widać z lektury modeli jakości oprogramowania, modele były ściśle związane z określoną perspektywą patrzenia na jakość. Perspektywy opisane w [KitPfe1996] określają różne wymiary jakości jako wymiar użytkownika, producenta, produktu jako takiego, oraz wartości zmierzonej. Z kolei w normach ISO/IEC 9126:2001 i ISO/IEC rozróżnia się 3 poziomy jakości: wewnętrzną, zewnętrzną i użyteczną. Należy rozważyć, czy modele jakości opisane w poprzednim rozdziale wyczerpują różne perspektywy jakie można przypisać aktorom, czyli osobom mającym związek z oprogramowaniem. Biorąc pod uwagę model zarządzania usługami IT (ITIL) [OGC2000], traktujący oprogramowanie szerzej niż tylko jako produkt, a mianowicie postrzegając oprogramowanie wraz z jego dynamicznym udostępnieniem jakości jako jeden byt zwany usługą, wprowadza pojęcia następujących klas aktorów: 1. Dostawca IT przedstawiciel firmy zajmującej się utrzymaniem usług IT, 2. Klient właściciel biznesowy podejmujący decyzję o potrzebach oraz ograniczeniach ekonomicznych, 3. Użytkownik osoba korzystająca z usługi IT Ten podział nie jest odległy od opisanych wcześniej modeli, jednakże po wprowadzeniu pojęcia usługi IT należy zauważyć, że pod pojęciem Dostawcy IT, kryje się szereg ról, których postrzeganie jakości może być zupełnie inne: 4. Właściciel - klasa przedstawicieli producenta których celem jest maksymalizacja ekonomicznych aspektów związanych z wytwarzaniem/rozwojem/utrzymaniem oprogramowania, 5. Deweloper - przedstawiciele producenta będący osobiście zaangażowani w proces wytwarzania oprogramowania, 6. Operator/Serwisant - przedstawiciel wykonawcy, dostawcy usługi IT lub wewnętrznego IT Klienta będący osobiście zaangażowany w proces utrzymania działającego oprogramowania.

10 Czym jest jakość oprogramowania 10 Twierdzenie, że każda z powyższych klas aktorów postrzega jakość oprogramowania w inny sposób jest oczywistością. W poniższej tabeli nakreślono główne (w sposób nie wyczerpujący) aspekty jakości oprogramowania istotne dla danej klasy aktorów: Aktor Klient (Acquirer) Użytkownik (User) Właściciel IT (Supplier) Deweloper (Developer) Operator/Serwisant (Operator/Maintainer ) Główne cechy jakości Całkowity Koszt Utrzymania, użyteczność Użyteczność, ergonomia Koszt całkowity wytworzenia i utrzymania, przychody związane z oprogramowaniem Prostota technologiczna, przejrzystość części wewnętrznej Niezawodność oprogramowania, łatwość instalacji i odtworzenia Tabela Perspektywy jakości oprogramowania względem aktorów Rozważając czy powyższa tabela jest wyczerpująca i oddaje wszystkie możliwe spojrzenia na jakość oprogramowania należy oczywiście odpowiedzieć, że nie. Niemniej jednak obserwując rozwój rynku IT oraz rosnący poziom organizacji wewnętrznej dostawców, należy spodziewać się, że zmierzanie rynku w stronę rosnącej liczby usług świadczonych w oparciu o infrastrukturę IT, modele jakości będą rozróżniały co najmniej powyższą listę perspektyw. Jakie będą przyszłe spojrzenia na modele jakości ze względu na rodzaje oprogramowania (z półki, na zamówienie, usługi świadczone przez sieć)? Otóż wschodzącą gwiazdą na rynku IT stają się usługi publiczne świadczone drogą elektroniczną. Usługi te różnią się od usług dedykowanych tym samym czym oprogramowanie powielane od oprogramowania dedykowanego. Dostawca i użytkownik stają się anonimowi, nie negocjują SLA (Service Level Agreement), nie rozliczają się w oparciu o przedyskutowane raporty. Niemniej jednak należy definiować i mierzyć jakość oprogramowania bazującego na takich usługach i to uwzględniając wszystkie perspektywy aktorów opisanych w rozdziale. Usługi te zostaną zbudowane w oparciu o oprogramowanie mające swoją jakość wewnętrzną, zewnętrzną i użyteczną. Całościowa jakość z punktu widzenia użytkownika będzie jednak czymś więcej. Autorzy modelu SQuaRE również zauważyli tą tendencję i ten przyszły model jakości nazwali Quality in use odróżniając jakość użyteczną oprogramowania jako Software quality in use.

11 Czym jest jakość oprogramowania Postrzeganie jakości 3.1. Subiektywizm w ocenie oprogramowania Wiele zjawisk obserwowanych przez człowieka daje się obiektywnie zmierzyć. Możemy na przykład porównać masę 2 obiektów, porównać ich długość itd. Możliwość wykonywania obiektywnych pomiarów jest cechą przypisywanym zjawiskom fizycznym. Oprogramowanie, a tym bardziej jego jakość jest bytem niematerialnym i stąd też stosowanie znanych w fizyce miar wydaje się być skazanych na niepowodzenie. Spoglądając na definicję jakości przytaczaną w poprzednim rozdziale: Jakość to zdolność przedmiotu do zaspokojenia zdefiniowanych i dorozumianych potrzeb [ ] [ISO/IEC 9126:2001, ISO/IEC 25000]. W tej definicji zaszyte jest twierdzenie, że kluczem do postrzegania jakości są potrzeby użytkownika zarówno te zdefiniowane, jak również te które są oczywiste i nie definiowane. Jedną z najbardziej znanych prac odnoszących się do analizy potrzeb człowieka jest piramida potrzeb wg Maslowa [Mas1943]. Maslow podzielił potrzeby na potrzeby niższego rzędu (typu D) charakteryzujące się tym, że człowiek nie zdaje sobie sprawy z ich istnienia dopóki są zaspokojone (np. potrzeby fizjologiczne) oraz potrzeby wyższego rzędu (typu B) pojawiające się w sytuacji zaspokojenia potrzeb niższego rzędu, charakteryzujące się nie wygasaniem wraz z ich zaspokajaniem. Podobne zjawisko zaobserwowali filozofowie i ekonomiści zajmujący się pojęciem wartości dziesiątki lat przed Maslowem, a ich prace zaliczane są do tzw. marginalizmu [Sti1972]. W XIX w. Austrii powstał nurt ekonomii nazywany szkołą psychologiczną, którego przedstawiciele dokonali ważnych obserwacji w obszarze potrzeb i ich zaspokajania. Herman Heinrich Gossen sformułował tzw. prawo malejącej użyteczności krańcowej, które sprowadza się do stwierdzenia, iż kolejne jednostki danego dobra mają coraz mniejszą przydatność dla nabywcy [Gos1854]. Klasycznym przykładem jest szklanka wody, której wartość dla człowieka maleje wraz z poziomem zaspokojenia pragnienia, aż do momentu kiedy nabycie kolejnej szklanki wody nie jest warte najmniejszego kosztu. Jak więc zauważyli następcy Gossena siła potrzeby zależy nie tylko od jej rodzaju ale również od bieżącego poziomu zaspokojenia i poziomu jej pilności [Wie1889]. Czy podobnie jest z cechami jakościowymi oprogramowania? Czy, o ile istnieją potrzeby jakości związane z oprogramowaniem, ich zaspakajanie prowadzi do zmniejszenia ich wartości? Jeżeli tak, to oznaczałoby, że dla nabywcy oprogramowania największe znaczenie mają cechy, które dotychczas nie były zaspokojone, a w trakcie długotrwałego użytkowania wady i braki jakościowe przysłaniają zalety oprogramowania. Zastanawiając się nad tym w jaki sposób człowiek postrzega jakość produktu nie sposób nie zauważyć, że większość psychologów i neuro-psychologów rozróżnia trzy poziomy świadomości i układów mózgu [MaKr1973]. Podążając za nazewnictwem Zygmunta Freuda mamy zatem Id obszar odpowiedzialny za prymitywne odruchy, Ego obszar emocji i Superego obszar rozumnego postrzegania świata [Fre1923]. Freud zauważył również, że człowiek postrzega świat głównie warstwą podświadomą, co z kolei potwierdza pewien brak racjonalizmu przy wydawaniu opinii np. o jakości.

12 Czym jest jakość oprogramowania 12 Warto wspomnieć jeszcze o dwóch filozofach: Immanuelu Kancie, który budując teorię postrzegania stwierdził, że człowiek posługuje się apriorycznymi poglądami i wiedzą, która powoduje, że zamiast postrzegać rzeczywistość postrzega tylko swoje poglądy i zamiast poznawać rzeczywistość poznaje samego siebie [Cas1981]. David Hume z kolei prowadził badania na temat źródła pochodzenia poglądów człowieka. W czasie swoich obserwacji zauważył, że ludzie mają naturalną tendencję do odrzucania obserwacji niezgodnych z pozostałymi, lub niezgodnych z tym w co wierzą [Str1977]. Współczesna psychologia potwierdza powyższe obserwacje formułując tezę, że wszystko co postrzega człowiek jest jedynie interpretacją stanu jego umysłu [LSF2000]. Jakie jeszcze cechy ludzkiej psychologii mogą wpływać na percepcję oprogramowania? Wydaje się, że najczęściej spotykanymi w organizacjach są: konformizm i podążanie za autorytetami pracownicy firmy w nielicznych sytuacjach pozwalają sobie na inne poglądy niż reszta zespołu lub niż wybitni eksperci. Co więcej ludzie w naturalny sposób ograniczają swoje chęci poznania przyjmując pierwszą obserwację/hipotezę odpowiadającą ich oczekiwaniom jako wystarczająco dobrą i odrzucając potrzebę jej weryfikacji [Kel1958]. Wniosek z powyższych rozważań pokazuje jak bardzo złożonym pojęciem jest postrzeganie jakości oprogramowania. W kontekście definicji bazującej na zaspokojeniu potrzeb, a idąc dalej w kontekście postrzegania przez odbiorcę, że jego potrzeby zostały zaspokojone niewiele udało się do obecnej chwili zbadać i ustalić. Niniejszy artykuł przedstawia kilka wstępnych obserwacji, które będą badane w przyszłości Charakterystyki i pomiar jakości Charakterystyki jakości jako konsekwencja potrzeb Jakość, jak to zostało opisane w poprzednim rozdziale definiowana jest jako szereg charakterystyk, z których dla każdej określa się pod-charakterystyki i atrybuty, a następnie z nimi wiąże się sposób pomiaru. Ponieważ jednak w tym rozdziale rozważania dotyczą rozszerzonego pojęcia jakości należy zadać pytanie, czy i które atrybuty reprezentują potrzeby użytkowników. Przyjmując model SQuaRE [ISO/IEC 25000:2005]jako ustalony zbiór charakterystyk oraz punkt widzenia jakości użytecznej należy skupić uwagę na następujących sześciu charakterystykach. Zastanówmy się jakie potrzeby mogą być związane z każdym z tych atrybutów: użyteczność (usability in use) przykładem potrzeby może być potrzeba zwiększenia produktywności, obniżenia kosztów pracy, zwiększenia satysfakcji z użytkowania itd. zgodność z kontekstem (context in use) przykładem potrzeby może być zgodność ze specyfiką wykonywanych zadań bezpieczeństwo (safety in use) przykładem potrzeby może być potrzeba ochrony własnych pracowników, ochrony obiektów oraz przeciwdziałanie zagrożeniom dla tychże poufność (security in use) tu potrzeba koncentruje się na przeciwdziałaniu ryzyku ujawnienia wrązliwych danych

13 Czym jest jakość oprogramowania 13 łatwość użycia (adaptability in use) potrzebą uzasadniającą ten kontekst jest potrzeba łatwego wdrażania nowych pracowników i realizowania nowych funkcji w systemie Widać zatem, że do każdej charakterystyki daje się dopasować potrzebę, jednakże w większości przypadków są to potrzeby wyższego rzędu (typu B) z punktu widzenia potrzeb człowieka (poza zapewnieniem bezpieczeństwa, które można powiązać z typem D w przypadku zapewniania bezpieczeństwa sobie i osobom najbliższym). Jakie są konsekwencje tej obserwacji? Otóż zgodnie z teorią Maslowa powyższe potrzeby mogą być specyfikowane, rozumiane i właściwie postrzegane może być ich spełnienie jeżeli osoba oceniająca jest w stanie zaspokojenia innych swoich potrzeb, lub, na co wskazują badania, jest na tyle wyedukowana, aby takie potrzeby rozumieć. Kolejną ciekawą obserwacją odnoszącą się do potrzeb jest ich ważność wynikająca z bieżącego doświadczenia osoby oceniającej, specyfikującej wymagania oraz aktualnego poziomu zaspokojenia tych potrzeb [Wie1889]. Jeżeli przykładowo stabilność oprogramowania nigdy nie była problemem dla użytkownika definiującego wymagania nie będzie takiego wymagani wskazywał, a wręcz uważał je za nadmiarowe. Z drugiej strony użytkownik spragniony stabilności może przedkładać to wymaganie ponad wszystkie pozostałe. Siłę niezaspokojonych potrzeb oraz charakterystykę ich nasycania należałoby gruntownie zbadać Manifestowane charakterystyki jakości Interesującym i ważnym podziałem charakterystyk jakości jest podział, ze względu na możliwość obserwacji przez użytkownika. Istnieją cechy, które w sposób oczywisty można obserwować jak choćby zrozumiałość interfejsu, szybkość działania, produktywność etc. Jednakże definicje jakości oprogramowania nie ograniczają jego definicji do takich charakterystyk, które użytkownik może samodzielnie obserwować. Przykładowo poufność danych, niezawodność, odtwarzalność w przypadku awarii pozostają w sferze domniemania użytkownika. Czy takie cechy, choć nie mierzalne mają wpływ na ocenę użytkownika i satysfakcję z posiadanego oprogramowania? Naturalnie. Dobrym przykładem mógłby być użytkownik, który był zadowolony z oprogramowania do czasu, kiedy dowiedział się, że jego działanie jest niezgodne z jakimś mało znanym przepisem, który jednak jest na tyle ważny, że dyskwalifikuje działające rozwiązanie. Badania cech jakości innych niż oprogramowanie produktów wskazują, że cechy domniemane w umiarkowany sposób poprawiają zadowolenie użytkownika z oprogramowania, natomiast nie spełnione potrafią wpływać na niezadowolenie z rozwiązania silniej niż cechy manifestowane [Ste1989]. Czy produkt jakim jest oprogramowanie podlega takim samym zależnościom? Wydaje się, że tak, aczkolwiek wymaga to przeprowadzenia szeregu badań Zmiana percepcji w czasie Postrzeganie jakości w cyklu posiadania oprogramowania podlega ciągłym zmianom. Wcześniej wspomniano, że w początkowej fazie znaczenie ma łatwość nauczenia się i posługiwania się

14 Czym jest jakość oprogramowania 14 systemem, a w kolejnych zaspokajanie innych potrzeb. Na użytek niniejszego artykułu podzielono cykl posiadania oprogramowania na: etap poprzedzający zakup, wdrożenie, eksploatacja, zmiana do oprogramowania oraz wycofanie, z tym że ostatni etap nie jest już opisany, z racji tego że postrzeganie jakości produktu w tym czasie nie ma praktycznego znaczenia, choć oczywiście oprogramowanie wciąż jest oceniane Etap wyboru, zakup i wdrożenie Proces zakupowy zgodnie z większością publikacji w tym obszarze rozpoczyna się od uświadomienia sobie potrzeby po którym następuje zbieranie informacji o możliwościach [KH2007]. Tu pojawiają się dwie istotne grupy wydarzeń w znacznym stopniu determinujące postrzeganie jakości w początkowych fazach użytkowania systemu. Po pierwsze dostawcy oprogramowania starają się uświadamiać użytkownikom ich potrzeby sprawiając, że dotychczas używane rozwiązania tracą wartość w oczach użytkowników. Po drugie rozbudzają nadzieję na wyższy poziom zaspokojenia wszystkich potrzeb użytkowników (czyli powiększenie dotychczasowego poziomu zaspokojenia potrzeb). Procesy powyższe zachodzą w różnym stopniu wśród różnych decydentów. W szczególności można wyróżnić dwie skrajności osoby oczekujące na nowe rozwiązanie jako spełnienie ich wszystkich (również nowo-uświadomionych) potrzeb oraz osoby, które są z założenia niechętne zmianom, ponieważ stopień zaspokojenia ich potrzeb jest na tyle wysoki, że nie są w stanie przeciwstawić wysiłku i ryzyka wkładanego w pozyskanie nowego rozwiązania przeciw potencjalnemu wzrostowi satysfakcji z używania systemu. Co więcej osoby decydujące o ważności cech przyszłego oprogramowania kierują się bieżącym poziomem braku zaspokojenia i bieżącymi potrzebami uznając najpilniejsze za najważniejsze, odkładając przyszłe potrzeby na dalszy plan [Wie1889]. W czasie testów akceptacyjnych następuje pierwsza konfrontacja systemu z oczekiwaniami (nierzadko stymulowanymi w procesie handlowym). Konfrontacja ta odbywa się również w sytuacji, kiedy oprogramowanie (czy to z półki, czy budowane na zamówienie) jest do tego najmniej przygotowane, bo ma najniższy w historii współczynnik zgodności z docelowym kontekstem użycia i nierzadko działa jak torowanie (priming) w świadomości oceniających. W efekcie użytkownik bardzo szybko przyjmuje za obowiązującą opinię, że oprogramowanie jest niezgodne z wymaganiami. Taki sposób rozumowania jest typowy dla sposobu postrzegania i uczenia się świata przez ludzi [KW2003] i dotyczy również poznawania jakości oprogramowania Eksploatacja Niezależnie od problemów w trakcie testów po wdrożeniu i rozpoczęciu eksploatacji oprogramowania pojawia się kolejny rozdźwięk pomiędzy potrzebami, a ich zaspokojeniem. Okazuje się, że potrzeby, na które użytkownik nie zwracał uwagi w trakcie wyboru rozwiązania były i są krytycznie ważne dla prowadzonej działalności, a ponieważ do tej pory były zaspokojone, to zgodnie z pierwszym prawem

15 Czym jest jakość oprogramowania 15 Gossena [Gos1854] zwartościowano je jako mniej istotne. Ich niezaspokojenie pokazuje jednak jak bardzo są ważne Zmiana Naturalnym elementem cyklu posiadania oprogramowania jest podejmowanie decyzji o zmianie, rozszerzeniu posiadanej infrastruktury, funkcjonalności. Proces ten składa się podobnie jak proces zakupu z uświadomienia potrzeby i zebrania informacji. Pojawia się pewna delta w spodziewanej jakości oprogramowania (lepiej zaspokoi potrzeby), oraz koszt jej wykonania. Zakładając, że jest to delta mogąca zmieniać kompozycję nasycenia wszystkich potrzeb należy przyjąć, że zmiana może zarówno poprawiać satysfakcję i zaspokojenie pewnych potrzeb, jak i pogarszać zaspokojenie innych potrzeb. Analogicznie jak to ma miejsce przy zakupie przy wartościowaniu zmiany decydenci ulegają wrażeniu, że zaspokojone potrzeby są mniej istotne, co może prowadzić do akceptacji faktu obniżenia ich zaspokojenia Jakość postrzegana - podsumowanie Podsumowując niniejszy przegląd filozoficznych i psychologicznych spojrzeń na produkt jakim jest oprogramowanie w kontekście zaspokojenia potrzeb użytkownika należy stwierdzić, że obszar ten wymaga badań. Budowa obiektywnych klasyfikatorów jakości, które byłyby w stanie określić jaką ocenę jakości oprogramowania w czasie będzie wydawała konkretna osoba wymaga takich narzędzi jak model potrzeb użytkownika, model zmienności potrzeb użytkownika oprogramowania w czasie itd. Proste podsumowanie rozważań Gossena i Maslowa prowadzi do wniosku, że użytkownik uświadamia sobie głównie niezaspokojone potrzeby i te najpilniejsze stają się najważniejsze, co z kolei prowadzi do niezauważana pozytywnie zaspakajających potrzeby cech oprogramowania, a zatem ocena jakości użytkownika ma tendencję do bycia negatywną, co oczywiście nie oznacza, że oprogramowanie jest obiektywnie wadliwe, a jest bardziej konsekwencją sposobu postrzegania i uczenia się świata przez ludzi. 4. Standardy rynkowe 4.1. Czy są potrzebne Pytanie zawarte w tytule tej sekcji jest raczej pytaniem retorycznym. Brak standardów jakości na rynku oprogramowania to szereg problemów i wątpliwości nie tylko dla Klientów i Użytkowników oprogramowania, ale także dla producentów. W przypadku producentów wątpliwości dotyczą tego co należy zrobić, aby osiągnąć produkt wysokiej jakości, lub inaczej mówiąc aby jakość produktu stała się elementem przewagi konkurencyjnej.

16 Czym jest jakość oprogramowania 16 Powszechne wdrażanie normy ISO 9001 oraz entuzjastyczne przyjęcie pierwszej wersji ISO 9126:1991, jak również adaptowanie praktyk CMMI pokazują, że producenci nie obawiają się inwestycji i nakładów na szeroko rozumiane zapewnianie jakości. Pomimo tego, że na rynku pojawiają się bardziej szczegółowe wytyczne odnośnie wymogów dla oprogramowania niż w ISO/IEC 9126:2001 lub ISO/IEC (na przykład w ISO 9241) to brakuje mechanizmów i standardów, które pozwoliłyby materializować wysiłki producentów i byłyby rozpoznawalne dla użytkowników Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne W dniu dzisiejszym obowiązują następujące akty prawne: Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2005 r. Nr 64, poz. 565) Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz.U. z 2005 Nr 217, poz. 1836) Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej (Dz.U. z 2005 Nr 214, poz. 1781) Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2005 Nr 212, poz. 1766) Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu i zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. z 2005 Nr 205, poz. 1692) Pomimo mogącej toczyć się dyskusji o ich przydatności lub nie, o tym co wnoszą, a co mogłyby wnosić (główny zarzut dotyczy tego, że są zbyt pobieżne), zaskakujący jest fakt, że prawo to jest praktycznie martwe. Zgodnie z przepisami podmioty realizujące zadania publiczne i udostępniające interfejsy elektroniczne powinny publikować testy akceptacyjne nie są publikowane. Producenci systemów komunikujących się z tymi rozwiązaniami powinni przesyłać podmiotom realizującym zadania publiczne informacje o nowych wersjach oprogramowania wypuszczanego na rynek nie przesyłają, a nawet gdyby przesłali to urzędnicy, z którymi autorzy omawiali sposób procesowania wynikający z ustawy nie mieliby pojęcia co z takimi informacjami zrobić. Ustawa stosowana może być wyłącznie przez podmioty realizujące zadania publiczne, a tymczasem cały rynek IT wymaga wsparcia dla użytkowników w określaniu jakości oprogramowania Podjęta inicjatywa Należy rozważyć jakie cechy powinny mieć standardy jakości dla oprogramowania aby ich pojawienie się wniosło realną wartość dla producentów i użytkowników. Autor tej publikacji wymienia kilka

17 Czym jest jakość oprogramowania 17 cech, które zostały zidentyfikowane w ramach prac nad stworzeniem standardów jakości oprogramowania [SASO2007] Perspektywa klienta i użytkownika Przyjęto, że standardy rynkowe mają dostarczać informacji o produkcie użytkownikom i klientom branży IT. Wynika z tego, że zarówno w obszarze definiowania standardu główny głos powinni zabierać użytkownicy i klienci jak również, że to właśnie perspektywa użytkownika powinna być dominującym zestawem cech jakościowych. Warto zauważyć, że choć drugi z wyżej wymienionych postulatów zauważono już w modelu Boehm [Boe1979], o tyle dotychczas budowane modele powstawały głównie na podstawie analiz naukowych lub prac organizacji wywodzących się z branży IT Oparcie merytoryczne o osiągnięcia dziedzinowe Postulat ten jest raczej oczywisty i w pewnym sensie dobrze uzupełnia opisany powyżej. Celem jaki mają do osiągnięcia standardy jest stworzenie porozumienia pomiędzy społecznością odbiorców i producentów oprogramowania. Jednym z podstawowych wymagań dla takiego porozumienia jest jednoznaczna komunikacja, stąd też oparcie się o dotychczasowe dokonania w obszarze modelowania jakości oprogramowani i korzystanie z bieżących i przyszłych prac w tej dziedzinie wydaje się być nieodzowne Obiektywizm i własność standardu Standard jakości oprogramowania nie może preferować producentów oprogramowania, konkretnych technologii czy platform. Wynika z tego, ze właścicielem standardu powinna być organizacja nonprofit skupiająca użytkowników i przedstawicieli IT. Quality in use Usability in use Adaptability In use Safety in use Security In use Context in use Effectiveness in use Productivity in use Satisfaction in use Usability in use compliance Learnability in use Flexibility in use Accessibility in use Adaptability in use compliance Risks to the operator in use Risks to the public in use Commercial risks in use Risk of software corruption in use Safety in use compliance TO BE DEFINED Security in use compliance User types in use Tasks in use Environments in use Context in use compliance Usability & Adaptability cert. Safety & Security cert.

18 Czym jest jakość oprogramowania 18 Rys. Trzy rodzaje certyfikatów mapowane na model SQuaRE w ISO/IEC CD 4.7. Porównywalność Kolejnym wymogiem dla standardu jest możliwość odniesienia go do różnych produktów i wyciągnięcie wniosków o ich jakości z możliwością wprowadzenia relacji porządku. Patrząc na model SQuaRE można zauważyć, że część charakterystyk dotyczy kontekstu użycia aplikacji, który ze swojej natury nie nadaje się na obiektywny element standardu (mógłby powstać szereg standardów dla konkretnych dziedzin zastosowania). W modelu wybrano zatem te charakterystyki, które zapewniają możliwość stworzenia obiektywnych i porównywalnych miar, a ich odniesienie do SQuaRE prezentuje rysunek Dostęp do dokumentacji i możliwości ewaluacji Standard może upowszechnić się jedynie wtedy, kiedy jego dokumentacja będzie powszechnie dostępna (najlepiej nieodpłatnie) oraz będzie istniało wiele podmiotów na rynku, które będą doradzały producentom w zakresie stosowania standardu lub dokonywały ewaluacji oprogramowania (nadania odpowiedniego znaku jakości). Audits And Notifies Orders Evaluation Evaluator Developer Registers Certificate for software Rys. Proces wydawania certyfikatu zgodności: SASO notyfikuje firmy wykonujące badania (Evaluatorów) producent zwraca się do firmy wykonującej badania firma potwierdza zgodność z wymogami i przyznaje znak jakości (oraz informuje SASO) SASO prowadzi nadzór nad systemem

19 Czym jest jakość oprogramowania Podsumowanie Niezależnie od liczby zdefiniowanych do tej pory modeli jakości oprogramowania na rynku brakuje standardów, które pozwoliłyby producentom dyskontować swoje inwestycje w jakość produktów IT. Standardy odnoszące się do obecnych modeli zastosowania oprogramowania oraz przyszłych wyzwań, takich jak SOA mogą stać się istotnym elementem uwagi producentów, oraz dać im możliwość stosowania rozwiązań, których oczekuje społeczność użytkowników. Przygotowywane standardy powinny bazować na dotychczasowych dokonaniach naukowych w obszarze modelowania jakości oprogramowania oraz rozszerzać te modele o konkretne decyzje o włączaniu, wyłączaniu i wadze poszczególnych charakterystyk. Jedna z pierwszych tego typu inicjatyw bazująca na modelu SQuaRE i nie opublikowanych jeszcze normach ISO/IEC i innych z serii ISO/IEC powstała w Polsce [SASO2007]. Inicjatywa ta nie jest skazana na sukces, ale z pewnością może wpłynąć zarówno na wewnętrzny rynek IT w Polsce jak również wizerunek polskiego IT na zewnątrz. 6. Bibliografia Aryst1999 Arystoteles, Kategorie, w Dzieła Wszystkie, Wydawnictwo Naukowe PWN, 1990 Bach Bach J., Good Enough Quality: Beyond the Buzzword, IEEE Computer Society, August 1997 (Vol. 30, No. 8) pp BAJ1993 Bazzana G., Anderson O., Jokela T., ISO 9126 and ISO 9000: friends or foes?, Software Engineering Standards Symposium BasWei1984 Basili V., Weiss D., A methodology for collecting valid software engineering data, IEEE Transactions on Software Engineering, Vol SE-10, 1984 Beg Begier B., Inżynieria Oprogramowania - Problematyka Jakości, WPP 1999 Beg2003 Begier B., Ocena jakości wyrobu programowego przez użytkowników, w: Z.Huzar, Z. Mazur (ed.): Problemy i metody inżynierii oprogramowania, pp , WNT, Warszawa 2003 ( Boe1978 Boehm B., Brown J., Lipow M., MacCleod G, Characteristics of software quality, NY, American Elsevier, 1978 BowWig1985 Bowen T., Wigle G., Tsai J., Specification of Software Quality Attributes, RADC-TR-83-37, Vol 1-3, Boeing Aerospace Company, 1985 Cas1981 Cassirer E., Kant's Life and Thought. Translation of Kants Leben und Lehre. Trans., Jame S. Haden, intr. Stephan Körner., New Haven, Yale University Press, 1981 CotSur2006 Côté M-A, Suryn W., Georgiadou E., "Software Quality Model Requirements for Software Quality Engineering", Software Quality Management & INSPIRE Conference (BSI) 2006 DiaSli1997 Diaz M., Sligo J., How Software Process Improvement Helped Motorola, IEEE Software 17(5), 1997 Dro Dromey R., A Model For Software Product Quality, Australian Software Quality Research Institute Dro1998 Dromey R., Software Product Quality: Theory, Model and Practises, Australian Software Quality Research Institute Dromey1996 Dromey R., Cornering the Chimera, IEEE Software 13(1), 1996 Dymek Dymek D., Zarządzanie jakością oprogramowania komputerowego, Akademia Ekonomiczna w Krakowie 2000 Eic2003 Eickelman N., An Insider s View of CMM Level 5, IEEE Software 20(4), 2003

20 Czym jest jakość oprogramowania 20 Fre1923 Freud S., Das Ich und das Es (The Ego and the Id), 1923 Gasik2004 Gasik S., Jakość w projektach informatycznych, Gos1854 Gossen H., Die Entwicklung der Gesetze des menschlichen Verkehrs und der daraus fließenden Regeln für menschliches Handel (The Development of the Laws of Human Intercourse and the Consequent Rules of Human Action), 1854 HamMan Hamrol A., Mantra W., Zarządzanie jakością, PWN 2002 HamMay Hamlet D., Maybee J., Inżynieria Oprogramowania WNT 2003 IEEE1998 Standard for a Software Quality Metrics Methodology, IEEE 1061, 1998 ISO14598:1999 JTC1/SC7, Information technology - Software product evaluation, International Standardization Organization, 1999 ISO15504:1998 SPICE, JTC1/SC7, International Standardization Organization, 1998 ISO/IEC 25000:2005 JTC1/SC7, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE), International Standardization Organization, 2005 ISO/IEC CD JTC1/SC7, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE), Dokument wewnętrzny ISO/IEC JTC1/SC7, Obecnie w stadium CD Commision Draft, 2007 ISO 9001: TC176/SC2, Quality management systems Requirements, International Standardization Organization, 1994 ISO 9001:2000 TC176/SC2, Quality management systems Requirements, International Standardization Organization, 2000 ISO 9126:1991 JTC1/SC7, Information Technology Software Product Quality, International Standardization Organization, 1991 ISO/IEC 9126: JTC1/SC7, Software engineering - Product quality, International Standardization Organization, 2001 ISO/IEC :1998 TC159/SC4, Ergonomic requirements for office work with visual display terminals (VDTs), International Standardization Organization, 1999 Jag Jagielski J., Kwantytatywna ocena jakości przyrządu pomiarowego, Pomiary Automatyka Robotyka 7-8/2004 Jasz Jaszkiewicz A., Inżynieria Oprogramowania, Helion 1997 Kan2003 Kan S., Metrics and Models in Software Quality Engineering (second edition), Addison Wesley, 2003 Kan2006 Kan S., Metryki i modele w inżynierii jakości oprogramowania, Wydawnictwo Naukowe PWN, 2006 KH Katsioloudes M., Hadjidakis S., International Business: A Globar Perspective, Butterworth-Heinemann, 2007 Kel Kelman H., Compliance, identification, and internalization: three processes of attitude change, Journal of Conflict Resolution, 1958 KobPol2003 Kobyliński A., Polak P., Analiza polskojęzycznej literatury z zakresu "Inżynierii oprogramowania", w: Problemy i metody inżynierii oprogramowania, Z. Huzar, Z. Mazur [red.], WNT, 10, Koby Kobyliński A., ISO/IEC analiza modelu jakości produktów programowych, w: Systemy Wspomagania Organizacji 2003, T. Porębska-Miąc, H. Sroka [red.], Prace Naukowe AE w Katowicach, 10, Koby2005 Kobyliński A., Modele jakości produktów i procesów programowych, Oficyna Wydawnicza Szkoły Głównej Handlowej, 2005 KW2003 Kolb B., Whishaw I., Fundamentals of Human Neuropsychology, 2003 KitPfle1996 Kitchenham S., Pfleeger, Software Quality: The Elisive Target, IEEE Software 13(1) 1996 Kili Kiliński A., Jakość, WNT 1979 LSF2000 Libet B., Sutherland K., Freeman A.,The Volitional Brain: Towards a Neuroscience of Free Will, 2000 MaKr1973 MacLean P., Kral V., A Triune Concept of the Brain and Behaviour, Ontario Mental Health Foundation, 1973 Mas1943 Maslow A., A Theory of Human Motivation, Psychological Review 50, 1943 McCa1977 McCall J., Richards P., Walters G., Factors In software quality, Griffiths Air Force Base, NY, Rome Air Development Center Air Force Systems Command, 1977