ZARZDZANIE CELAMI BIZNESOWYMI: SATYSFAKCJA

KLIENTA I JAKO ZINTEGROWANA

NewQuality

Tradycyjne podejcie do zapewnienia jakoci oraz do testowania oprogramowania, okrela jako jako
zgodno z wymaganiami funkcjonalnymi, oraz nielicznymi niefunkcjonalnymi (wydajno, do wsko
rozumiana uyteczno).
Z punktu widzenia jakoci dowiadczanej przez klienta-uytkownika jest to podejcie niewystarczajce:
produkt informatyczny speniajcy wymagania projektu, w trakcie ktrego powsta, czsto nie jest udanym produktem z punktu widzenia marketingowego, a wiele dobrych programw czy urzdze zawierajcych oprogramowanie wbudowane, mimo swojej niezawodnoci, nie zadowolio klientw, nie
odnioso sukcesu rynkowego, ani nie przyczynio si do usprawnienia procesw biznesowych, ktre
miay wspiera.
Jak poczy ze sob te dwa obszary? to temat niniejszego artykuu.

1. TRADYCYJNE PODEJCIE DO JAKOCI OPROGRAMOWANIA

1.1. JAKO PRODUKTU
Tradycyjne podejcie do jakoci produktu znajdujemy - przykadowo - w normie ISO 9126 [1]. Norma ta okrela model atrybutw jakoci oprogramowania, zarwno funkcjonalnych jak i niefunkcjonalnych; okrela take pojcie
jakoci wewntrznej (z punktu widzenia producenta oprogramowania) i jakoci zewntrznej (z punktu widzenia klienta i uytkownikw). Norma zaznacza
take istnienie rnych interesariuszy jakoci (ang. stakeholders), dla ktrych
te same obiektywne miary jakoci oznaczaj odmienn subiektywn jako.
Zagadnienia te s dobrze znane, opisane m.in. w ksikach Andrzeja Kobyliskiego [2] lub Normana Fentona [3].
Naley jednak zaznaczy, e zasady zarzdzania jakoci produktu, dostpne i
opisane w normach, lub w ksikach, nie przystaj czsto do realiw przemysu informatycznego, gdzie jako oprogramowania wbrew zaleceniom teorii
- traktuje si niestarannie.
Duym problemem w praktyce jest po prostu zaniedbywanie wymaga; prawie kady z etapw procesu inynierii wymaga (pozyskiwanie, analiza, modelowanie, specyfikacja, walidacja, zarzdzanie zmianami) [4][3] jest w wielu

 NewQuality

projektach albo pomijany, albo realizowany nieprawidowo [5].

Rzadko spotyka si w projektach informatycznych prawidowo realizowany
proces zwany ledzeniem zwizkw wymaga (ang. requirements traceability),
pozwalajcy poprawnie identyfikowa relacje wymaga z innymi powstajcymi w projekcie artefaktami, takimi jak komponenty architektury oprogramowania, moduy kodu rdowego, czy przypadki testowe. W zwizku z tym,
ocena, na ile zakoczony projekt rzeczywicie spenia zawarte w wymaganiach
zaoenia, jest w wielu projektach fragmentaryczna, a czsto robiona po prostu na wyczucie.
Cho istnieje szereg komercyjnych narzdzi wspierajcych ledzenie zwizkw
wymaga [6], to bardzo rzadko udaje si je wykorzystywa cznie z narzdziami sucymi do zarzdzania projektem (jednym z nielicznych wyjtkw
jest aplikacja Concerto [7]), co powoduje, e wiedza na temat poziomu realizacji wymaga nie jest w peni wykorzystywana w zarzdzaniu projektami.
Innym, spotykanym w praktyce problemem jest niedostateczne uwzgldnienie
istnienia rnych interesariuszy (udziaowcw) wymaga. Na przykad, znanym zjawiskiem w wielu projektach jest eksplozja propozycji zmian interfejsu
uytkownika pod sam koniec projektu, w trakcie testw akceptacyjnych, co
spowodowane jest ignorowaniem uytkownikw kocowych podczas pozyskiwania wymaga, gdzie dominuj z jednej strony przedstawiciele biznesu, z
drugiej analitycy systemw.
Dalej, czsto zaniedbywane s inne wymagania ni funkcjonalne; wyjtkiem s
wymagania dotyczce wydajnoci i osigw, zwykle starannie okrelane i testowane, zwaszcza dla aplikacji webowych. Przykadem szczeglnie dotkliwych zaniedba, przybierajcych wrcz tragikomiczne proporcje, jest
okrelenie wymaga uytecznoci [8]. Mimo istnienia szeregu dobrze opisanych
zasad
zarwno
projektowania,
jak
i
testowania
ci1[10][11][12], interakcja wielu systemw z uytkownikami jest
niedostateczna.
Zapomina si czsto, lub wiadomie ignoruje taki kluczowy atrybut jakoci, jak
atwo utrzymania [16], przez co wiele niepoprawnych z punktu widzenia atwoci utrzymania, a czsto stosowanych rozwiza architektonicznych i programistycznych,
praktycznie
uniemoliwia
elastyczne
i
szybkie
dostosowywanie oprogramowania do zmieniajcych si potrzeb biznesowych.
Adam Kolawa, zaoyciel firmy Parasoft, porwnuje w swojej ksice [9] takie
______________
1

Zamiast mylcej, cho w inynierii oprogramowania powszechnie uywanej, nazwy uyteczno, niektrzy autorzy [8] posuguj si szerszym pojciem interakcja.

Zarzdzanie celami biznesowymi: satysfakcja klienta i jako zintegrowana

rozwizanie artobliwie do przyspawania koa do osi samochodu, zamiast

przymocowania go rubami. Niedostateczna atwo utrzymania, pod pewnymi wzgldami tosama z brakiem jakoci wewntrznej, jest jednak zarazem
istotnym niedostatkiem jakoci zewntrznej, poniewa pociga za sob i due
koszty zmian, i niemono ich realizacji dostatecznie szybko dla potrzeb biznesu, co oczywicie odbija si negatywnie na dowiadczeniu klientw.
Niedocenianie znaczenia niektrych atrybutw jakoci wie si porednio z
niedostatecznym zaangaowaniem wielu procesw biznesowych w proces informatyczny, o czym mwimy w rozdziale [1.3].
Szczeglne z punktu widzenia jakoci oprogramowania s rozmaite techniki
zwinne (ang. agile) [13][14], czy programowanie ekstremalne [15]. Nie negujc ich praktycznej skutecznoci, w kadym razie w maych i rednich przedsiwziciach informatycznych, nie sposb okreli ich metodyki inaczej, ni
jako osiganie jakoci metod prb i bdw, co cho bywa skutecznie, nie
zawsze jest sprawne, i nie w peni pozwala na trafne przewidywanie czasu
trwania projektw. Metodyki zwinne, cho z jednej strony mocniej ni tradycyjne angauj przedstawicieli uytkownikw w procesie wytwarzania oprogramowania, z drugiej strony, jednak - pomijajc systematyczny proces
inynierii wymaga - utrudniaj uwzgldnienie wszystkich interesariuszy oraz
kompleksowe spojrzenie na rna aspekty jakoci.

1.2. JAKO PROJEKTU I PROCESU INFORMATYCZNEGO

Denie do osignicia wikszej sprawnoci, skutecznoci i przewidywalnoci
projektw informatycznych pojawio si ju dawno. Powstay normy i metody
pomiaru nie tylko jakoci produktu, ale take projektu, tworzcego produkt. W
szczeglnoci, metody oszacowania i pomiaru przebiegu projektu zaczy suy trafniejszej estymacji pracochonnoci projektw, ju to na podstawie
atrybutw projektu (np. metoda COCOMO [17]), ju to na podstawie atrybutw wymaga (np. analiza punktw funkcyjnych [18]).
Kolejnym krokiem byo okrelenie zasad, pozwalajcych oceni zdolno danej
organizacji do realizacji projektw, na podstawie waciwoci procesu (organizacji, procedur, wzorcw, przy pomocy ktrych realizuje si projekty informatyczne). Istnieje wiele standardw, sucych do oceny tzw. dojrzaoci
procesw: CMM, SPICE (ISO/IEC 15504), SixSigma, TQM, rodzina standardw
ISO 9001, i wiele innych. Nie podajemy dla nich wszystkich odsyaczy do literatury, gdy bibliografa staaby si zbyt obszerna, wykraczajca poza cis tematyk tego artykuu.
Metody te, okrelajce wymagania wobec procesw oraz testujce (metod

 NewQuality

audytu), na ile dany proces te wymagania spenia, maj swoich zwolennikw i

przeciwnikw. Argumentem, czsto podnoszonym przez przeciwnikw tych
metod, jest brak empirycznie potwierdzonego powizania przyczynowoskutkowego (a nawet tylko sabe dane o istnieniu korelacji) midzy wysokimi
wynikami jakoci procesw, a jakoci zarwno projektw, jak i produktw
[2][3]. Istnieje wiele anegdot ilustrujcych, e dobry proces nie zawsze przekada si na skuteczny i sprawny projekt, ani na dobry produkt [19].
Metodyk udoskonalania procesw, do unikaln, jest ADP [19], cho nie
mona zaprzeczy, e pewne elementy takiego podejcia zawiera w sobie zarwno SixSigma [20], jak i szeroko rozumiana metoda TQM [21]. Podstawowe
dwa elementy ADP to jej (1) skalowalno; (2) stosowanie osiganej jakoci
produktu oraz sprawnoci projektw jako gwnej miary jakoci procesw, w
miejsce uywanej przez inne metodyki miary zgodnoci istniejcych procedur
z przyjtymi wzorcami. Metoda ADP jest prb przeniesienia na grunt inynierii oprogramowania klasycznych metod ulepszania procedur, stosowanych
m.in. w przemyle motoryzacyjnym, w celu stworzenia swoistej, przewidywalnej tamy produkcyjnej wytwarzania oprogramowania. ADP odwouje si do
klasycznych prac Deminga [22] i Jurana [23].

1.3. JAKO INNYCH PROCESW OPRCZ INFORMATYCZNEGO

Nie trzeba by specjalist od zagadnie jakociowych, aby spostrzec, e o sukcesie rynkowym produktu lub usugi informatycznej decyduje nie tylko wsko rozumiana jako samego produktu, ani nawet procesu, ktry produkt
stwarza, lecz take (a moe przede wszystkim) szereg innych procesw: sprzeda, marketing, wsppraca z kooperantami, zarzdzanie wiedz i zasobami
ludzkimi, obsuga klienta, nawet CSR2 firmy.
Znajduje to swoje odbicie w tym, e np. standardy CMMI oraz SPICE uwzgldniaj nie tylko jako (dojrzao) procesu informatycznego, ale take innych
procesw firmy. Jest to istotny krok w kierunku bardziej kompleksowego traktowania zagadnie jakoci, cho w praktyce przemysowej nie stosuje si na
razie takiego podejcia, aby uzyska kompleksowy pomiar jakoci wszystkich
procedur, otaczajcych konkretny produkt.

______________
2

CSR (ang. Corporate Social Responsility) odpowiedzialno spoeczna przedsibiorstw.

Zarzdzanie celami biznesowymi: satysfakcja klienta i jako zintegrowana

2. POJCIE JAKOCI W MARKETINGU

W biznesowych realiach, czsto wystpuje przepa midzy dziaami marketingu a informatyki, dosadnie opisywana przez liczne anegdoty, ktrych powszechnie znanym przedstawicielem s komiksy z serii Dilbert. To bardzo
niekorzystny stan rzeczy i firmy, ktre jako pierwsze skutecznie potrafi zbliy
do siebie dziaania obu tych dziaw, uzyskaj istotn przewag nad konkurencj [9].
Pojcia stosowane przez marketing do oceny jakoci produktw i usug, podobne s w gruncie rzeczy do poj stosowanych przez inynieri oprogramowania (cho inaczej brzmi ich nazwy) [24], natomiast uzupenione s o
kilka nie wystpujcych w inynierii oprogramowania wymiarw:

Pojcie marki, zbioru jakoci wielu, czsto rnorodnych produktw i

usug, majcej odrbne miary jakoci, nie zawsze identyczne z jakoci nalecych do marki produktw.

Uwzgldnienie zmiennoci poczucia jakoci produktu w czasie i w przestrzeni, zarwno geograficznej, jak i spoecznej [25].

Szczeglny nacisk na psychologiczne i spoeczne aspekty poczucia jakoci

klientw/uytkownikw, szczegowo cho nie w kontekcie marketingowym omwionych w [26]. Marketing w duym stopniu nastawiony jest
na wytwarzanie poczucia jakoci poprzez zmiany innych czynnikw ni
techniczna, wewntrzna jako samego produktu, co czsto jest przyczyn
inynierw wobec dziaa marketingowych, odbieranych jako oszukacze,
czego znakomitym przykadem s ponownie komiksy Dilbert.

Systematyczne uwzgldnienie aspektw kulturowych wpywajcych na

poczucie jakoci u klientw [24].

Wiele dziaa marketingu nastawionych jest nie tylko na zaspokojenie

istniejcych, uwiadomionych i wyartykuowanych potrzeb klientw, co
jest gwnym celem zarzdzania jakoci w inynierii oprogramowania,
lecz take na odkrycie nieuwiadomionych potrzeb, lub wrcz stworzenie
nowych potrzeb [25].

Dziaania majce na celu zapewnienie jakoci z punktu widzenia marketingu o wiele rzadziej ni w inynierii oprogramowania polegaj na systematycznym testowaniu, na ile prototyp produktu czy usuga, czy
otaczajce je procesy, speniaj okrelone i zaoone wymagania. Czstszym podejciem jest monitorowanie poziomu zadowolenia klientw z aktualnej wersji, w celu wykorzystania informacji do projektowania kolejnej

 NewQuality

wersji. Pod tym wzgldem, testowanie produktw informatycznych uprawiane wspczenie w ramach marketingu podobne jest do testowania
uytecznoci (interakcji), bdcego czciej sposobem na pozyskanie
(okrelenie) wymaga, a nie sprawdzeniem, na ile produkt spenia wymagania okrelone zawczasu. Takie podejcie realizuj rwnie w pewnym
stopniu metodyki zwinne.

2.1. ZARZDZANIE DOWIADCZENIEM KLIENTA

Nowoczesnym podejciem do zagadnie marketingu jest tzw. zarzdzanie dowiadczeniem klienta (ang. customer experience management, CEM [28]). Podejcie to zakada, e poczucie jakoci produktu/usugi u klienta zaley tylko w
czci od waciwoci tego produktu, a w przewaajcej mierze od innych
czynnikw, zwizanych z procesami reklamy, sprzeday, instalacji, obsugi posprzedaowej, produkcji, nawet sposobu fakturowania i windykacji, a take od
czynnikw nie dotyczcych samego produktu, lecz firmy lub marki, do ktrej
naley. Mechanizmy dziaania takich czynnikw opisuje w sposb popularny
[29].
Cho opisywane w ksikach i znane, takie podejcie dopiero toruje sobie drog do rzeczywistoci marketingowej w firmach.

3. ZINTEGROWANY MODEL JAKOCI

W kontekcie szerokiego rozumienia jakoci przez marketing, zwaszcza realizowany w postaci zarzdzania dowiadczeniem klientw, tradycyjny zakres
wymaga i testowania oprogramowania wydaj si bardzo niedostateczne:
kontrolowanie szczegw technicznych zamiast caoksztatu. Jednak faktem
jest, e niespenienie wymaga jakoci w zakresie tych - pozornie drugorzdnych - szczegw technicznych, bywa czynnikiem decydujcym o poczuciu
jakoci, ktrego adne, najdoskonalsze dziaania marketingowe, sprzedaowe
czy inne nie s w stanie zmieni [30], [31].
Marketing / zarzdzanie dowiadczeniem klienta s w porwnaniu z dyscyplin inynierii oprogramowania bardzo nieprecyzyjne, polegajce gwnie
na metodzie prb i bdw, a nie na systematycznym definiowaniu zaoe/wymaga ani na systematycznym sprawdzaniu (testowaniu), na ile modele i prototypy speniaj te zaoenia. Cho istnieje wiele sposobw
marketingowego testowania [24] (uwaga: nikt w marketingu nie uywa oczywicie terminu testowanie), to brak im technik systematycznych, a zwasz-

Zarzdzanie celami biznesowymi: satysfakcja klienta i jako zintegrowana

cza formalnych, jakie stosuje si w tradycyjnym testowaniu oprogramowania

[32].
Najwyraniej, wielki potencja kryje si w poczeniu silnych stron obu brany:
technik modelowania i systematycznego testowania inynierii oprogramowania z kompleksowym, integralnym podejciem marketingu/zarzdzania dowiadczeniem klientw.

3.1. POSZERZONY MODEL INYNIERII WYMAGA

Inynieria wymaga [4] nie wykorzystuje ani do pozyskiwania, ani do walidacji
wymaga, wielu spord technik i sposobw znanych marketingowi [24]. Dzia
marketingu bywa najczciej tylko jednym z wielu interesariuszy wymaga. O
wiele wicej na ten temat tego, jak identyfikowa interesariuszy i pozyskiwa
wymagania, mona dowiedzie si na kursach sprzeday, ni na szkoleniach
dotyczcych inynierii wymaga.
Poszerzenie zakresu inynierii wymaga o obszary, nalece do zarzdzania
dowiadczeniem klienta, pozwoli osign znacznie lepsze zaspokojenie potrzeb biznesu i potrzeb uytkownikw systemw informatycznych.

3.2. POSZERZONY MODEL TESTOWANIA OPROGRAMOWANIA

Testowanie oprogramowania, obecnie dziedzina ograniczona do sprawdzania
zgodnoci oprogramowania z (nietestowanymi) wymaganiami, poszerzone do
wymiarw testowania produktw i procedur (procesw) w wietle zarzdzania dowiadczeniem klienta3, czyli zgodnie z poszerzonymi wymaganiami [3.1],
moe sta si najwaniejszym obszarem dziaania firm, scalajcym dziaania w
dotychczasowej praktyce rozdzielone.

3.3. MODEL JAKOCI ZINTEGROWANEJ

Poniej zarysowujemy model jakoci zintegrowanej, sucy po wypenieniu
go treci specyficzn dla danego produktu jako lista kontrolna do dziaa
realizowanych w projekcie informatycznym, oraz innych dziaa cyklu ycia
______________
3

Przez klienta rozumiemy tutaj zarwno tradycyjnie rozumianych klientw zewntrznych,

kupujcych produkty firmy, jak i szerzej wszystkich udziaowcw i uczestnikw projektu informatycznego, ktrych dowiadczenia wchodz w zakres integralnego zarzdzania dowiadczeniami klientw.

 NewQuality

danego produktu.
Docelowo, taki model powinien mie struktur hierarchiczn: rne wersje i
pod-wersje modelu dla rnego rodzaju produktw.
Model jest w podstawowej czci trjwymiarowy:

Atrybuty jakoci

Procesy, w ktrych funkcjonuje dany produkt (bezporednio i porednio)

Interesariusze (w kadym z procesw)

Dla kadego obszaru modelu (atrybut/proces/interesariusz) model definiuje

metody pozyskiwania stosowanych wymaga, oraz techniki testowania (techniki testowania obejmuj zarwno techniki projektowania przypadkw testowych, jak i metody ich wykonywania).
Dla kadego z trzech wymiarw modelu, liczba rnych wartoci tego wymiaru
jest inna dla rnych produktw.
Poniszy przykad ilustruje zastosowanie modelu dla produktu typu usuga
telekomunikacyjna.
3.3.1. Instalacja usugi dla abonenta
Instalacja usugi dla danej centrali telefonicznej z punktu widzenia: instalatora,
kierownika usugi, kierownika obszaru, uytkownikw centrali, biura obsugi
klienta.
Atrybuty jakoci dla kadego interesariusza: atwo nauczenia si, atwo
wykonywania, konieczno dostpu, stabilno, jako dokumentacji, czasochonno, moliwo kontroli wykonania.
3.3.2. Instalacja usugi razem z podczeniem urzdzenia dostpowego
Interesariusze i atrybuty jak wyej.
3.3.3. Przeniesienie usugi pod inny adres
Interesariusze i atrybuty usugi jak wyej.
3.3.4. Modyfikacja konfiguracji usugi
Interesariusze i atrybuty jak wyej.

Zarzdzanie celami biznesowymi: satysfakcja klienta i jako zintegrowana

3.3.5. Wstawienie faktury abonentowi za wykorzystanie usugi w okresie

rozliczeniowym.
Ten skadnik usugi telekomunikacyjnej jest opisany poniej w penym zakresie, uwzgldniajcym wszystkie aspekty zintegrowanej jakoci usugi telekomunikacyjnej.

Poprawne rozliczenie z systemu bilingowego (zgodna liczba zarejestrowanych i fakturowanych sygnaw, uwzgldniajca rne objte abonamentem taryfy, numery bezpatne itp.)

Poprawne rozliczenie z systemu bilingowego dotyczy poprawnego okresu

Poprawne rozliczenie dotyczy ostatniego okresu

Poprawne rozliczenie pozwala na atw identyfikacj rozliczenia, rozpatrywanie niezgodnoci zgoszonych przez abonenta oraz jest wygodn
podstaw umoliwiajc debugowanie systemu bilingowego, oraz systemu
wystawiania faktur.

Poprawne rozliczenie przetestowane jest pod wzgldem funkcjonalnym

dla nietypowych i niepoprawnych klas rwnowanoci (okres niepeny na
kocu okresu, okres niepeny na pocztku okresu, okres pusty, itp.)

Faktura jest poprawna pod wzgldem prawnym

Faktura zawiera poprawne dane klienta

Faktura zawiera numer telefonu klienta

Faktura jest atwa do odczytania i zrozumienia: informacje najwaniejsze, czyli numer telefonu abonenta, data patnoci, suma brutto patnoci
oraz numer konta, na ktry naley dokona patnoci, s wyranie widoczne.
Faktura jest wygodnie rozplanowana na papierze wydruku.

Sumy dodatkowe, np. za instalacj, napraw lub przeniesienie s poprawnie i wyranie zidentyfikowane.

System obsugi faktur (telefoniczny) umoliwia identyfikacj faktury zarwno na podstawie numeru telefonu, imienia i nazwiska abonenta, numeru klienta, adresu klienta itp.

Faktura wysyana jest na poprawny adres.

Faktura wysyana jest na tyle wczenie, eby do koca terminu patnoci
pozostao co najmniej dwa tygodnie.

 NewQuality

4. LITERATURA DO ARTYKUU
[1] ISO 9126: http://en.wikipedia.org/wiki/ISO_9126
[2] Andrzej Kobyliski: Modele jakoci produktw i procesw programowych, Oficyna Wydawnicza SGH,
Warszawa 2005
[3] Norman Fenton, S. Pfleger: Software Metrics, A Rigorous and Practical Approach, International
Thomson Computer Press, 1996
[4] Karl E. Wiegers, Software Requirements, Microsoft Press, 2003
[5] REQB Requirements Engineering Qualifications Board: http://www.reqb.org/ (maj 2009)
[6] Lista narzdzi do ledzenia zwizkw wymaga: http://www.paper-review.com/tools/rms/read.php
(maj 2009)
[7] Narzdzie Parasoft Concerto: http://www.parasoft.com/jsp/products/concerto/home.jsp (maj 2009)
[8] Alan Cooper: Wariaci rzdz domem wariatw, Wydawnictwo Naukowo-Techniczne 2001
[9] Adam Kolawa: The Next Leap in Productivity, Wiley 2008
[10] Jakob Nielsen: Usability Engineering, Morgan Kaufman 1994
[11] SUMI (Software Usability Measurement Inventory), http://sumi.ucc.ie/ (maj 2009)
[12] WAMMI (Website Analysis and Measurement Inventory), http://www.wammi.com/ (maj 2009)
[13] http://www.agilemanifesto.org/ (maj 2009)
[14] Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices, Cambridge Press,
1999
[15] Kent Beck: Extreme Programming Explained - Embrace Change, Addison-Wesley Professional, 2000
[16] Thomas M. Pigoski: Practical Software Maintenance: Best Practices for Managing Your Software
Investment
[17] Barry W. Boehm i wspautorzy: Software Cost Estimation With COCOMO II, Prentice Hall PTR, 2000
[18] David Garmus, David Herron: Function Point Analysis, Addison-Wesley, 2001
[19] Adam Kolawa, Dorota Huizinga: Automated Defect Prevention Best Practices in Software
Management, Wiley, 2007
[20] Six Sigma: http://en.wikipedia.org/wiki/Six_Sigma
[21] R. Ashley Rawlings: Total Quality Management (TQM) , Author House, 2008
[22] W.E. Deming: The New Economics: For Industry, Government, Education, M.I.T. 1993
[23] Joseph M. Juran: Jurans Quality Handbook, McGraw-Hill, 2000
[24] Philip Kotler, Gary Armstrong, Veronica Wong, John Saunders: Principles of Marketing
[25] Philip Kotler: Jak kreowa i opanowywa rynki
[26] Radosaw Hofman: Postrzeganie jakoci oprogramowania (referat na KKIO 2009)

10

Zarzdzanie celami biznesowymi: satysfakcja klienta i jako zintegrowana

[27] Harry Beckwith: Sprzedawanie niewidzialnego
[28] Bernd H. Schmitt: The Customer Experience Management: A Revolutionary Approach to Connecting
with Your Customers
[29] Michael Levine: Rozbite okna, rozbita firma
[30] http://en.wikipedia.org/wiki/List_of_notable_software_bugs (czerwiec 2009)
[31] Ron Patton: Testowanie oprogramowania, Wydawnictwo MIKOM, 2002
[32] Bogdan Wiszniewski, Bogdan Bereza-Jarociski: Teoria i praktyka testowania programw,
Wydawnictwo Naukowo-Techniczne, 2006
[33] Norman Fenton i M. Neil: Risk Assessment with Bayesian Networks, w przygotowaniu: Chapman
and Hall, 2010
[34] Bogdan Bereza-Jarociski: Inynieria oprogramowania jak zapewni jako aplikacjom, Helion
2009

11