Zapewnianie jakości w projekcie informatycznym

Transkrypt

1 Magazine Zapewnianie jakści w prjekcie infrmatycznym Autr: Rafał Dbrsielski O autrze: Abslwent Plitechniki Gdaskiej, wydziału Elektrniki Telekmunikacji i Infrmatyki, ukczył również studia pdyplmwe z zakresu Inżynierii Oprgramwania i Zarządzania Prjektami. Zawdw, na c dzie, zajmuje się czynnie planwaniem, zapewnianiem i sprawdzaniem jakści w prjektach infrmatycznych. Jest autrem szkle i warsztatów z zakresu zarządzania prjektem infrmatycznym, zarządzania i zapewniania jakści prduktów infrmatycznych raz mdeli prcesów inżynierii prgramwania. Interesuje się analizą i mdelwaniem prcesów bizneswych w rganizacjach jak również psychlgią biznesu. rdbrsielski@pap.cm.pl Intermediate Level 3 Magazine Number Jakść w prjekcie Sectin in the magazine Wprwadzenie C jest dbre, Fedrusie? A c nie jest? Czy pwinniśmy kgś pytać by się teg dwiedzieć? (Platn, kł 370 BC) Zapewnianie jakści prduktów na swją histrię i jak dwdzi pwyższy cytat, sięga czasów bardz dległych.

2 Przez wiele lat metdy i systemy zapewniania jakści przeszły długą drgę i pdlegały wielu zmianm. Ich największy rzwój przypada jednak na drugą płwę ubiegłeg stulecia. W tym czasie bserwwaliśmy również grmny wzrst knkurencji na rynku prduktów infrmatycznych, a także wzrst czekiwa w stsunku d ich jakści i szerk rzumianej użytecznści. Dziś d systemów infrmatycznych nie wymaga się już tylk prstej niezawdnści czy jakiejklwiek realizacji pszczególnych przepadków bizneswych za pmcą kmputera. W pprzednim numerze magazynu c0re, w artykule Jakśd prduktów infrmatycznych, przedstawiny zstał mdel jakści systemu infrmatyczneg, który pdkreśla jej wielwymiarwśd, a sukces prjektu infrmatyczneg craz częściej mierzny jest siąganiem czekiwanych krzyści bizneswych przez rganizację decydującą się zakupid i wdrżyd system infrmatyczny. W związku z tym, rla i zadania prcesów zapewniania jakści w prjekcie infrmatycznym pdlegały i pdlegają nadal ciągłej ewlucji. T na nich spczywa dpwiedzialnśd za zbudwanie mdelu jakści (indywidualnie dla rganizacji, prjektu czy dla każdeg z jeg prduktów i pdprduktów), wytwrzenie systemu knkurencyjneg, intuicyjneg, spełniająceg wymagania szerkieg spektrum interesariuszy. Craz częściej człnkwie zespłów prjektwych, którzy są dpwiedzialni za jakśd, uczestniczą w działaniach marketingwych, birąc dpwiedzialnśd za prawidłwe dczytanie ptrzeb klientów i ptymalne kreślenie zakresu systemu szacując wartśd ddaną płynącą z jeg wdrżenia, kszty i czas wytwrzenia. Wszystk p t, aby trafid z prduktem w kres największeg zaptrzebwania na rynku, c przyniesie klientwi i dstawcy największe zyski. Z statnim zadaniem wiąże się również szacwanie, czy prdukt siągnął już wystarczając wyską jakśd, a dalsze prace nad jej pdnszeniem nie będą dla prduktu destrukcyjne lub czy nie spwdują znacznych późnie we wdrżeniu, c z klei mże prwadzid d strat ptencjalnych krzyści finanswych czy też utraty udziałów w rynku. Pwyższe rzważania dwdzą, że zapewnianie jakści w prjekcie stał się już dziedziną interdyscyplinarną. Kt dpwiada zatem za jakść systemu infrmatyczneg? Jednym z zasadniczych błędów w prcesie zapewniania jakści jest (niestety) częst sptykane w praktyce twierdzenie, że w ramach prjektu infrmatyczneg należy wyróżnid grupę sób dpwiedzialnych za jakśd prduktów czy prcesów. Ten mit jest prpagwany i uwieczniany pprzez pwływanie d życia sbneg zespłu, zwykle zwang Sftware Quality Assurance (SQA) i ddanie mu przywileju i dpwiedzialnści za jakśd. W praktyce jakśd jest i pwinna byd dpwiedzialnścią każdeg. Osiąganie wyskiej jakści musi byd zintegrwane z wszystkimi czynnściami prcesów zachdzących w prjekcie, a nie stanwid sbną dyscyplinę. Takie pdejście czyni każdeg dpwiedzialnym za jakśd prduktów, nad którymi pracuje i za pieczłwite wyknywanie czynnści w ramach prcesów, w które jest zaangażwany *12+. Pmim, że każdy pnsi dpwiedzialnśd za jakśd, frmalnie, za zapewnienie jakści w prjekcie dpwiedzialny jest Kierwnik Prjektu. Dzięki sprawwaniu przez nieg dpwiednieg nadzru raz

3 ustanawianiu dpwiednich prirytetów mżemy mied pewnśd, że jakśd będzie dpwiedni zarządzana, mierzna i siągana. Zapewnianie jakści pdejście tradycyjne a pdejście współczesne Współczesne pdejście d zapewniania jakści prjektu infrmatyczneg znacznie się zmienił i nieustannie ewluuje w kierunku siągania zapewnienia satysfakcji klienta. Pczątkw prjekty infrmatyczne rzumiały siąganie jakści prduktu infrmatyczneg jak zbudwanie systemu zgdneg z przyjętymi uprzedni wymaganiami. Jakśd prduktu ceniana była głównie przez prducenta czy też ekspertów - specjalistów z dziedziny infrmatyki - a wady traktwan jedynie jak dstępstwa d specyfikacji. Dążn d pzyskania i pracwania mierzalnych i biektywnych kryteriów jakści. Nadrzędną cechą jakści jest jej dynamika i subiektywizm. Dlateg becnie jakśd rzumie się jak stpie, w jakim system czy prdukt infrmatyczny spełnia czekiwania klienta. Najcenniejsze pglądy jakści systemu infrmatyczneg frmułuje klient zamawiający system raz jeg użytkwnicy. Obecne systemy zapewniania jakści parte są na analizie celów bizneswych, analizie wymaga, badaniach knkurencji i badaniach marketingwych raz na cenie zadwlenia klientów. Tabela nr 1 przedstawia prównanie tradycyjneg i nwczesneg pdejścia d pjęcia jakści w infrmatyce. Pdejście tradycyjne Jakśd t Jakśd cenia Zgdnśd prduktu z wymaganiami Prducent, ekspert C t jest wada? Kryteria jakści Odstępstw d specyfikacji Obiektywne i mierzalne Dtyczą atrybutów, charakterystyk i parametrów technicznych System zapewnienia jakści Analiza wymaga, zdefiniwanie i kntrla prcesu wytwarzania, standaryzacja, dkumentacja Pdejście współczesne Jakśd t Jakśd cenia Stpie spełnienia czekiwa użytkwnika (klienta) Klient, użytkwnik C t jest wada? Niespełnienie czekiwa użytkwnika Kryteria jakści Subiektywne ceny użytkwnika Stpie satysfakcji użytkwnika System zapewnienia jakści Analiza celów bizneswych, analiza wymaga, badania knkurencji i marketingwe, cena zadwlenia klientów Tabela 1, Pdejście tradycyjne a nwczesne d pjęcia jakści w infrmatyce Pdejście tradycyjne nastawine był na wykrywanie defektów, natmiast zapewnianie jakści, częst rzumiane jak testwanie, przypisywan specjalnie wydzielanym kmórkm rganizacyjnym. Dziś już wiadm, że wytwarzanie systemów wyskiej jakści musi byd kupine wysiłkiem niemalże całeg przedsiębirstwa. Prcesy zapewniania jakści bejmują prcesy wytwórcze, prdukty (głównie cząstkwe), dkumentacje, ludzi itp. Większśd wysiłku pwinna byd skierwana na zapbieganie defektm i wadm, a nie na wykrywanie ich i usuwanie.

4 Sprawdzanie jakści a zarządzanie jakścią Systemy jakści również dynamicznie zmieniają się, ewaluwały d tzw. systemów kntrli jakści, pprzez systemy zapewniania jakści d zarządzania nią. Sprawdzanie jakści traktuje system jak black bx, a jakśd prgramwania sprawdzana jest a psteriri. Cały system jakści zbudwany jest wkół idei testwania funkcjnalneg. Jeg efektywnśd, przytaczana w *8+, szacwana jest na 70% usuwanych defektów, zatem 30% trafia d klienta. Pwduje t wzrst ksztów pielęgnacji naprawczej, sięgających nawet d 25% ksztów wytwrzenia. Jak wiemy, kszt naprawy pjedynczeg błędu w skcznym systemie jest wyski (reguła 1:10) a gólny kszt sprawdzania jakści mże sięgad d 50% ksztów wytwrzenia. Najisttniejsze w tym pdejściu jest t, że inne ważne atrybuty jakści są w tutaj ignrwane, gdyż p prstu nie mżna ich zbudwad pprzez testwanie. Zarządzanie jakścią mtywuje d szerkieg ceniania jakści wszystkich prduktów cząstkwych, również w trakcie prcesu ich wytwarzania. Prcesy wytwórcze są zdefiniwane, pmiarwane, a ich realizacja również pdlega sprawdzaniu. Prcesy te mają zdefiniwaną strukturę, są pdzielne na etapy z wynikającymi z nich prduktami. Techniki ceny jakści (przeglądy, inspekcje) są w stanie wykryd 80-90% defektów. Dla pszczególnych etapów prcesu, jak i dla całeg przedsięwzięcia definiwane są zalecane metdy i narzędzia, wprwadzane są pmiary prcesu i prduktu. Standaryzacja struktury prcesu i jeg uzbrjenia narzędziweg raz nadanie mu pewneg stpnia pwtarzalnści, pzwalają wykrzystywad te pmiary d szacwa kluczwych parametrów, takich jak kszt, czas realizacji, kcwa gęstśd defektów itp. na pdstawie danych histrycznych. Umżliwia t kntrlę nad ryzykiem przedsięwzięcia pprzez pdejmwanie akcji naprawczych, zanim sytuacja stanie się niebezpieczna. Zarządzanie jakścią w prjekcie infrmatycznym Cele prcesu zarządzania jakścią prjektu W prjekcie infrmatycznym przed prcesem zarządzania jakścią stawiane są następujące cele: zidentyfikwad i zdefiniwad właściwe wskaźniki (metryki) akceptwalnej jakści, zidentyfikwad, definiwad i zaplanwad dpwiednie pmiary, które będą użyte w prcesie badania i ceny jakści, zidentyfikwad i dpwiedni rzwiązad zagadnienia i prblemy jakściwe tak szybk i efektywnie jak t mżliwe. Zarządzanie jakścią jest realizwane pprzez wszystkie dyscypliny, czynnści, fazy i iteracje mdelu inżynierii prgramwania. Oznacza t, że należy realizwad, mierzyd i ceniad jedncześnie: jakśd prcesu c jest nastawine na pprawne budwanie prduktów, jakśd prduktu c jest nastawine na zbudwanie pprawneg prduktu. Zarządzania jakścią prcesu Jakśd prcesu dnsi się d stpnia, w jakim przyjęte, zaakceptwane prcesy, uwzględniając pmiary i kryteria jakści, są wdrżne i stswane w celu wytwrzenia prduktów. Jak wiemy, wszystkie prcesy składają się z czynnści prdukcyjnych i tzw. czynnści wyższeg rzędu, zarządczych. Czynnści prdukcyjne mają rzeczywisty, namacalny wpływ na prdukt kcwy. Czynnści pzstałe mają

5 pśredni wpływ na kcwy prdukt, wyknywane są pdczas np. planwania, zarządzania i szacwywaniu zada. Zadaniem i efektem mierzenia i zapewniania jakści prcesu jest: właściwe, efektywne zarządzanie zasbami, właściwe zarządzanie ryzykiem i pstępwanie z nim, zbieranie danych w celu usprawnienia prcesów. Z praktyczneg punktu widzenia stswanie w prjekcie infrmatycznym sprawdznych rynkw mdelów prcesów i zasad raz siągniecie przez nie wyskieg pzimu wdrżenia przekłada się na jakśd prduktów, a ryzyk wyprdukwania prduktów niskiej jakści maleje i jest skutecznie redukwane. Zarządzania jakścią prduktów Zarządzanie jakścią prduktów kncentruje się na wyprdukwaniu właściwych, spełniających wymagania interesariuszy, wszystkich prduktów będących celem realizacji prjektu infrmatyczneg. Pwyżej uzgdniliśmy, że zapewnianie jakści musi dbywad się we wszystkich dyscyplinach inżynierii prgramwania. W ramach teg artykułu skupię się na dwóch, ramwych, kluczwych dyscyplinach wymaga i testwania, które w tradycyjnym, pierwtnym pdejściu stanwiły wejście i wyjście prcesu prdukcyjneg. Elementem wielu definicji wyskiej jakści systemu infrmatyczneg jest spełnienie wymaga stawianych systemwi czy czekiwa interesariuszy/udziałwców. Udziałwcem jest niewątpliwie użytkwnik kcwy, ale musimy uwzględniad także innych: kupująceg, kntrahenta, administratrów, kierwnika przedsięwzięcia, czy kgklwiek inneg, kt jest dstatecznie zaintereswany, alb kg ptrzeby muszą byd zaspkjne pprzez przedsięwzięcie. *12+ Dyscyplina wymagań - rzpznawanie ptrzeb udziałwców Aby wytwrzyd system ceniny przez jeg dbirców, zespół twórców musi rzumied knkretne ptrzeby udziałwców i cel bizneswy zlecenidawcy. Ważne jest, abyśmy aktywnie zbierali wszystkie typy żąda udziałwców (surwe dane wejściwe, służące wyrażaniu ptrzeb udziałwców) w ciągu całeg kresu trwania przedsięwzięcia. Na pczątku mżemy krzystad z wywiadów, kwestinariuszy i sptka rbczych, później będziemy zbierali żądania zmian, raprty usterkach i żądania rzbudwy. Te żądania będą zwykle niejasne i wielznaczne i częst będą miały pstad zaptrzebwania (na przykład ptrzebuję łatwiejszych spsbów dzielenia się mją wiedzą stanie przedsięwzięcia, ptrzebne mi zwiększenie mjej wydajnści, musimy zwiększyd efektywnśd systemu ). Takie żądania udziałwców twrzą niezbędne warunki d zrzumienia ich rzeczywistych ptrzeb i pznawania krytycznych uwag c d wymaga stawianych naszym prduktm. A t z klei stanwi ważną częśd układanki, która pzwli nam rzpznad wszystkie dlaczeg i c dtyczące zachwa systemu. *12+ W dalszych persnalnych czy grupwych dyskusjach należy przekud pszczególne zaptrzebwania na tzw. właściwści systemu zachwania na wyższym pzimie, rzumiane jak usługa, która ma byd świadczna przez system, bezpśredni spełniająca ptrzebę użytkwnika *12+. W wyniku takiej dyskusji trzeba zmienid/przesunąd myślenie użytkwnika d c d jak. Dpier dgłębne rzumienie ptrzeb udziałwców i przekucie ich na właściwści systemu, pzwala nam na rzpczęcie prac nad klejnym pzimem szczegółwści tegż pracwania w celu dkładneg przekazania twórcm teg, c system pwinien rbid (zamiast Alu, prgramuj system d autmatyczneg zawiadamiania listach pczty elektrnicznej ). Użyteczne staje się tu mdelwanie bizneswe i systemwe, za pmcą któreg będziemy mgli przetłumaczyd te ptrzeby i właściwści na

6 specyfikację, którą będzie mżna prjektwad, implementwad i testwad. Tu również uaktywnia się prces zapewniania jakści, któreg celem jest zbadanie min. spójnści, mierzalnści i testwalnści wymaga. Pwyższe działania w ramach dyscypliny wymaga pwinny nam pzwlid zrealizwad następujące cele: uzyskad i trzymad zgdę klientów i innych udziałwców c d teg, c system pwinien rbid i dlaczeg; pmóc twórcm systemu w lepszym zrzumieniu wymaga stawianych systemwi; kreślid granice systemu; stwrzyd pdstawy planwania technicznych treści iteracji (prcesu wytwórczeg); stwrzyd pdstawy estymacji ksztów i czasu budwy systemu; kreślid interfejs użytkwnika dla systemu kncentrując się na ptrzebach i celach użytkwników. Należy przypmnied, że isttne jest, aby zbierane wymagania, a następnie testy i pszczególne pmiary klasyfikwad knsekwentnie d przyjęteg mdelu jakści i dknywad ich analizy i syntezy pprzez pryzmat celu biznesweg zlecenidawcy. Dla przykładu, mdel klasyfikujący atrybuty jakściwe wg RUP, jak i inne pisywane w literaturze mdele zwykle jednakw dknują pierwtneg pdziału na wymagania funkcjnalne i niefunkcjnalne. Wymagania funkcjnalne Wymagania funkcjnalne służą d pisywania zachwa systemu przez frmułwanie warunków dtyczących danych wejściwych, które mają byd spełnine. Wymagania niefunkcjnalne Aby siągnąd pzim jakści ptrzebny użytkwnikwi kcwemu, trzeba wypsażyd system w spry zestaw właściwści nie wymieninych w wymaganiach funkcjnalnych dtyczących teg systemu. Aby system takie właściwści uzyskał, musi spełniad jeszcze ddatkwe wymagania nazywamy je niefunkcjnalnymi. W statecznym rzrachunku są ne pd każdym względem równie ważne dla spłecznści użytkwników kcwych, jak wymagania funkcjnalne. Stsując metdę klasyfikacji FURPS, mżna wyróżnid następujące niefunkcjnalne atrybuty jakści: użytecznśd wymagania c d użytecznści dtyczą czynników ludzkich: estetyki, łatwści panwania, łatwści używania raz spójnści interfejsu użytkwnika, dkumentacji użytkwnika i materiałów szkleniwych, niezawdnśd wymagania c d niezawdnści dtyczą częstści błędów i ich dtkliwści, zdlnści dnawiania, przewidywalnści i dkładnści, efektywnśd wymagania c d efektywnści narzucają warunki na wymagania funkcjnalne na przykład wymaganie, które kreśla częstśd transakcji, szybkśd, dstępnśd, czas reakcji, czas dnwy alb zajętśd pamięci, przy której dana czynnśd będzie musiała byd wyknywana, łatwśd wspierania (pielęgnwalnśd) wymagania c d łatwści wspierania dtyczą testwalnści, pielęgnwalnści i innych cech niezbędnych, aby system zachwał zdlnśd d prawidłwej pracy p ddaniu g d użytku. Te wymagania są unikatwe w tym sensie, że mgą dtyczyd nie tylk systemu, ale także prcesu twrzenia systemu alb rzmaitych artefaktów prcesów. Wartśd tych definicji plega na tym, że umżliwiają twrzenie szablnów alb list, ułatwiających frmułwanie wymaga i cenę kmpletnści, a także prawidłwe rzumienie wyników tej pracy. Mówiąc inaczej, jeżeli zbadamy wymagania z wszystkich tych kategrii i je zrzumiemy, t będziemy mieli pewnśd, że naprawdę pdjęliśmy te wymagania, które mają największe znaczenie, zanim jeszcze zaczniemy pważnie inwestwad w dane przedsięwzięcie. System, który nie spełnia wymaga niezawdnści lub efektywnści wynikających z innych wymaga, jest

7 tak sam zły jak system, który nie jest w stanie spełnid jakiegklwiek zadaneg wymagania funkcjnalneg. *12+ Ocena jakści prduktów Dyscypliną dpwiedzialną za cenę jakści prduktów prjektu infrmatyczneg jest testwanie. Stsuje je się w różnych celach zależnych d siągnięteg pzimu zaawanswania prjektu, jeg prduktów, włżneg i zaplanwaneg wysiłku. Zarządzanie, mierzenie i cena jakści prduktów i prcesów pwinna byd przeprwadzana przez cały cykl życia prjektu i mdelu inżynierii prgramwania. Ocena jakści mże byd przeprwadzna kiedy wydarzy się jakieś isttne wydarzenie jak np. nwe, wymagające natychmiastwej reakcji zagadnienie ryzyka, nwe wymaganie lub kiedy zgdnie z przyjętym mdelem i planem prjektu ukczn w całści lub częściw prdukt pdlegający testwaniu (zebran wymagania, przygtwan przypadki testwe, dkumentację itp.). Zadaniem testwania nie jest wyłącznie prste wyszukiwanie błędów. Prces ceny jakści pwinien zapewnid: wykrywanie i dkumentwanie niedstatków zgdnie z kryteriami wystarczając dbrej jakści ; infrmwanie człnków zespłu pstrzeganej jakści prgramwania; ptwierdzenie knkretnymi dwdami słusznści załże pczyninych przy prjektwaniu i specyfikwaniu wymaga; ptwierdzenie, że prdukt prgramwy działa zgdnie z prjektem; ptwierdzenie, że wymagania zstały dpwiedni zaimplementwane. *12+ Zwykle w prjektach infrmatycznych testwanie pchłania d 30-50% łącznych ksztów twrzenia prgramwania. Niestety, w wielu przypadkach przeważa pinia użytkwników mówiąca tym, że prgramwanie w gólnści nie jest dstatecznie przetestwane. Pnieważ spsby, pzimy i zakres testwania zależy d wielu czynników (np. typu prjektu, zada, jakie będą wyknywad wdrżne prdukty prgramwe, technlgii, użytych narzędzi), w niniejszym artykule nie zstaną przedstawine uniwersalne spsby przeprwadzania czynnści testwych. Pniżej mówine zstały najczęściej sptykane błędy i przyczyny niskiej efektywnści prcesu testweg, których eliminacja mże prwadzid w praktyce d bniżania ksztów testwania i ryzyka wdrżenia prgramwania niskiej jakści. Zstały ne przedstawine w *11+. Przede wszystkim należy pamiętad, że testwanie nie jest pjedynczą czynnścią czy etapem działalnści, w którym cenia się jakśd. Aby wypełnid cel infrmwania na czas twórców siąganej jakści przez prgramwanie, testwanie musi rzpczynad się dpwiedni wcześnie i zarówn dtyczyd wczesnych prttypów, stabilnści i sprawnści architektury (jądra systemu), gdy jeszcze mżna ją pprawid jak i prduktu kcweg, pzwalająceg na cenę jeg gtwści d przekazania klientm. Zbyt późne rzpczęcie prcesów testwych pwduje zatracenie najważniejszej krzyści płynącej z prcesu testweg szansy na uzyskanie infrmacji, czy mamy jeszcze czas, budżet i zasby na t, aby jeszcze cklwiek z tym prduktem zrbid. Testwalnśd nie jest uwzględniana w prjekcie prduktu, w wyniku czeg częst wielkrtnie wzrasta złżnśd testwania, następują utrudnienia w autmatyzacji lub niemżnśd wyknania niektórych testów. Testwanie jest przeprwadzane bez jasn sfrmułwanych metd, zasad, wskutek czeg wyniki zmieniają się w zależnści d przedsięwzięcia, d przedsiębirstwa, a efektywnśd testwania zależy głównie d umiejętnści, pmysłwści i chwilwej dyspzycyjnści człnków zespłu testweg. Narzędzia, d których zależy efektywnśd są alb używane nieskutecznie alb wcale i dlateg t c wymaga największeg wysiłku najczęściej nie zstaje przetestwane. Testy rzadk są prwadzne autmatycznie,

8 najczęściej bez użycia narzędzi, które pzwalają na skuteczne zarządzanie zbirami danych testwych i wynikami testwania. Nie jest mżliwe całkwite przetestwanie prgramwania, dlateg strategia testwania musi byd dbierana zarówn metdycznie jak i dświadczalnie, a wiedza ta pwinna pdlegad zarządzaniu i prpagwaniu w rganizacji. Bardz częst testwanie graniczne jest d sprawdzania i ceniania atrybutów funkcjnalnych jakści, pmijając równie ważne atrybuty i kryteria użytecznści, efektywnści czy niezawdnści. Dla każdeg z pwyższych wymiarów jakści (czy wymaga) należy zdefiniwad (w zależnści d typu prjektu) dpwiedni sprirytetyzwane przypadki testwe, które będą wyknywane na różnych pzimach prcesu testweg [12]. Wyniki testwania pwinny byd jak najbardziej biektywne (mim subiektywnści mawianych definicji jakści), pparte dpwiednimi pmiarami według uprzedni uzgdninych, zatwierdznych metryk dnszących się zarówn d prduktów jak i prcesu. Pdsumwanie Prjekt infrmatyczny, zarządzanie nim i zarządzanie jakścią t nie sekwencja pszczególnych sprawdznych działa, ale skmplikwana sied aktywnści, które prwadzą d pwstania wielu prduktów. Transfer wysiłku sób dpwiedzialnych za zapewnianie jakści z testwania na pprawne zarządzanie prcesem i czynnściami zazębia się z jakścią prduktu i bardz częst granicza ryzyk pwstania prduktu złej jakści. Od pczątku rzwju infrmatyki rganizacje pszukiwały i pszukują wciąż dbreg przepisu gwarantująceg sukces pdczas realizacji teg typu prjektów. Kntynuując te rzważania, w następnym artykule z cyklu, pstawine zstanie pytanie C t są mdele prcesów i czy są ne nam ptrzebne? Literatura *1+ James Bach: Gd Enugh Quality: Beynd the Buzzwrd, IEEE Cmputer, Sierpie 1997 *2+ Anna Bbkwska: Inżynieria Oprgramwania, Studium Pdyplmwe Nwczesne Metdy Inżynierii Oprgramwania, edycja *3+ Grady Bch: Leaving Kansas IEEE Sftware. 15(1), Stycze/Luty 1998 *4+ Victr R. Basili: The gal questin metric apprach, ( Advanced Cmputer Studies, Department f Cmputer Science, University Of Maryland) *5+ Jhn Fdeh: What's n Yur Dashbard Better Sftware, Octber 2007 *6+ Janusz Górski: Zarządzanie prjektem infrmatycznym, Studium Pdyplmwe Nwczesne Metdy Inżynierii Oprgramwania, edycja *7+ Janusz Górski: Inżynieria prgramwania w prjekcie infrmatycznym, Zakład Nauczania Infrmatyki MIKOM, Warszawa 1999 *8+ Jerzy Kaczmarek: Metryki i zapewnianie jakści, Studium Pdyplmwe Nwczesne Metdy Inżynierii Oprgramwania, edycja *9+ Stephen H. Kan: Metryki i mdele w inżynierii jakści prgramwania, Wydawnictw Naukwe PWN SA, 2006 *10+ Adam Krczwski: Zarządzanie ryzykiem w prjektach infrmatycznych. Teria i praktyka, Wydawnictw Helin 2010 *11+ Per Krll, Philippe Kruchten: Ratinal Unified Prcess d strny praktycznej, Wydawnictw Naukw- Techniczne, Warszawa 2007 *12+ Philippe Kruchten: Ratinal Unified Prcess d strny teretycznej, Wydawnictw Naukw- Techniczne, Warszawa 2007 *13+ Zdzisław Szyjewski: Metdyki zarządzania prjektami infrmatycznymi, Wyd. PLACET, Warszawa 2004