Magazine

Jako produktw informatycznych

Autor: Rafa Dobrosielski O autorze: Absolwent Politechniki Gdaoskiej, wydziau Elektroniki Telekomunikacji i Informatyki, ukooczy rwnie studia podyplomowe z zakresu Inynierii Oprogramowania i Zarzdzania Projektami. Zawodowo, na co dzieo, zajmuje si czynnie planowaniem, zapewnianiem i sprawdzaniem jakoci w projektach informatycznych. Jest autorem szkoleo i warsztatw z zakresu zarzdzania projektem informatycznym, zarzdzania i zapewniania jakoci produktw informatycznych oraz modeli procesw inynierii oprogramowania. Interesuje si analiz i modelowaniem procesw biznesowych w organizacjach jak rwnie psychologi biznesu. Email: rdobrosielski@paop.com.pl

Intermediate
Level

2
Magazine Number

Jako w projekcie
Section in the magazine

Wprowadzenie
Smoliste grzzawisko, jakim jest inynieria oprogramowania, jeszcze przez dugi czas bdzie nie do pokonania. Mona si spodziewad, e czowiek nadal bdzie dy do budowania systemw bdcych na granicy dostpnoci lub wrcz niedostpnych; systemy oprogramowania s prawdopodobnie najbardziej skomplikowanym dzieem czowieka. Ta wyrafinowana sztuka tworzenia ich bdzie wymagad od nas cigej pracy nad rozwojem tej dziedziny, uczenia si budowania wikszych jednostek, najlepszego wykorzystania nowych narzdzi, najlepszego zastosowania sprawdzonych ju metod zarzdzania inynieri, kierowania si przede wszystkim zdrowym rozsdkiem... [9] Fredrick P. Brooks

Informatyka staa si dziedzin bardzo uniwersaln i w obecnych czasach dotyczy absolutnie kadego. W swoich opracowaniach Grady Booch *2+ pisze grnolotnie, e to ona jest motorem dzisiejszej gospodarki i ekonomii. Z wykorzystaniem informatyki rzdy realizuj swoje cele, a spoeczeostwa podstawowe potrzeby. Co wicej, ju dzi, z perspektywy zwykych ludzi, produkty informatyczne realizuj wikszod zadao nie tylko podczas naszej pracy, odpoczynku, nauki czy realizacji jakichkolwiek podstawowych usug (banki, kasy biletowe, urzdy, zakupy), ale coraz czciej odpowiadaj za nasze zdrowie i bezpieczeostwo. Rwnie dziki nim pokonujemy wczeniejsze bariery w odkrywaniu otaczajcego nas wiata a ludzie niepenosprawni odzyskuj podstawowy z nim kontakt. Zaistniaa uniwersalnod owocuje coraz wiksz wiadomoci spoeczeostwa odnonie stopnia, w jakim jakod naszego ycia zaley od jakoci produktw informatycznych. W zwizku z tym rosn te wymagania uytkownikw dotyczce zoonoci, kompleksowoci rozwizao informatycznych oraz ich jakoci. Z jednej strony stanowi to due wyzwanie dla firm informatycznych i stwarza ogromne moliwoci rozwoju, z drugiej, wanod i zoonod tych systemw oraz koniecznod dostarczenia ich w odpowiednim terminie (wprowadzenie usugi biznesowej) powoduje, e wci musz one dziaad na granicy ich wasnych moliwoci oraz ograniczeo technologii. Dzi specjalici z dziedziny technologii informatycznych uznawani s rwnie czsto za kreatorw postpu cywilizacyjnego jak obarczani win za nieudane projekty, stracony czas i zaprzepaszczone szanse. [6]. W niniejszej pracy, na wstpie przedstawiona zostanie specyfika projektw informatycznych, a nastpnie pojcie jakoci i sukcesu projektw informatycznych. Pozwoli to na wyodrbnienie i omwienie procesw, ktre z punktu widzenia zapewniania jakoci produktu s w projekcie szczeglnie wane.

Specyfika projektw informatycznych

Cech wyrniajc projekty informatyczne spord innych jest niewtpliwie duy odsetek projektw, ktre przekraczaj zaplanowany budet okoo 50%; i niewielki odsetek projektw kooczcych

si celebrowaniem sukcesu nieco ponad 30%. Na tak niechlubny wynik wpywa wiele cech charakteryzujcych projekty informatyczne. Przede wszystkim projekty i produkty informatyczne charakteryzuje szczeglna ich zoonod oraz natura oprogramowania, ktre jest abstrakcyjne. Tego typu projekty mog dotyczyd nieograniczonej liczby zmieniajcych si w czasie dziedzin problemowych (finanse, inynieria techniczna, zarzdzanie), ktre uzalenione s od zmieniajcego si prawa, rynku i technologii. *1+,*11+ Efekty znacznej czci procesu wytwarzania oprogramowania s mao czytelne czy wrcz niewidzialne dla zewntrznego obserwatora. Powoduje to due trudnoci weryfikacji poprawnoci zaimplementowanego rozwizania przez wytwrcw. Dodatkowo, trudnoci te powodowane s znaczn pracochonnoci i kosztem sprawdzenia wszystkich przypadkw uycia i danych wejciowych, niematerialnoci oprogramowania, wspbienoci wykonywanych przez nie dziaao i brakiem zasad skalowania bdw maa pomyka powoduje (czsto paradoksalnie) duy bd. [1],[11] W zwizku z powyszym, rwnie proces waciwej walidacji oprogramowania przez klienta moe byd przeprowadzany dopiero bardzo pno, kiedy oprogramowanie materializuje si, a jednoczenie wprowadzanie zmian jest najdrosze. Dziedzin informatyki charakteryzuje brak praw fizyki i innych, intuicyjnych, typowych ograniczeo daje to szerok swobod projektantom, co prowadzi do mnogoci potencjalnych rozwizao tego samego problemu. Rozwizania te najczciej oddziaywuj na szerokie otoczenie informatyzowanej dziedziny, a wprowadzana przez system zmiana wymusza kolejne i wymaga bardzo szerokiej analizy problemu, uwzgldnienia wpywu szerokiego spektrum interesariuszy zwykle spoza dziedziny informatyki. W tym zakresie napotykamy czsto na problemy komunikacyjne na styku klient wykonawca. Klienci firm informatycznych, a czsto i wytwrcy oprogramowania, nie zdaj sobie sprawy, e przy budowie systemw informatycznych, wraz ze wzrostem wielkoci projektu koszt jednostkowy nie maleje. Koszt projektu ronie nieliniowo wraz ze wzrostem jego wielkoci wzrost pracochonnoci jest wykadniczy ze wspczynnikiem >1 . Zarzdzanie projektem informatycznym jest cile powizane z metodyk wytwarzanie oprogramowania wybrana nieadekwatnie do rozwizywanego problemu metodyka wytwarzania doprowadzi do upadku projektu.

Sukces projektu informatycznego

Aby mc zajd si pojciem jakoci systemu informatycznego, metodami zapewniania jakoci produktw informatycznych, najpierw zdefiniujmy pojcie sukcesu projektu informatycznego. Zastanwmy si nad pytaniem: Co jest sukcesem projektu informatycznego? Najprostszym podstawowym kryterium byoby przyjcie, e sukces odniesiemy wtedy, kiedy produkt uda si zrealizowad w zaplanowanym budecie i czasie. W odniesieniu do projektu informatycznego takie kryterium, z praktycznego punktu widzenia,

wydaje si byd kryterium niewystarczajcym. Wytworzenie sprawnie dziaajcego, bezbdnego oprogramowania lub udana implementacja systemu, poparta i zweryfikowana etapem pilotaowego wdroenia rwnie nie pozwala nam na celebrowanie sukcesu. Podobnie, nie jest penym sukcesem uzyskanie zapaty za wykonanie projektu, czy odbir systemu przez zleceniodawc. Ze wzgldu na przedstawion powyej specyfik projektw informatycznych, sukces projektu informatycznego naley rozpatrywad wielowymiarowo. Przede wszystkim naley osobno zastanowid si, co jest sukcesem projektu z punktu widzenia najwaniejszych interesariuszy projektu osobno z punktu widzenia organizacji wykonawczej, kierownika projektu, poszczeglnych zespow wykonawczych i osobno z punktu widzenia zleceniodawcy, czyli zamawiajcego produkt informatyczny. Czsto te, niestety, inne kryteria stosuje klient zleceniodawca, a inne bezporedni uytkownik (operator), administrator systemu czy osoby, ktre za pomoc tego systemu s obsugiwane. Odpowiednio wywaone oczekiwania kadego z interesariuszy oraz tzw. krytyczne czynniki sukcesu daj si sklasyfikowad i opisad za pomoc modelu FURPS (opisanego poniej). Czsto ukooczenie projektu staje si celem samym w sobie, nie uwzgldnia faktu, e projekt jest tylko drog do wprowadzenia podanej zmiany biznesowej *8+. Z punktu widzenia wykonawcy nie bierze si pod uwag zgodnoci celw realizowanych projektw ze strategi rozwoju organizacji, a czynniki ryzyka zwizane z niewypenieniem przez projekt misji nie s identyfikowane [8].

Rzeczywisty sukces projektw, nie tylko informatycznych, polega na uzyskaniu przez zamawiajcego korzyci biznesowych, ktre mog nastpid dopiero wiele miesicy po zamkniciu projektu [8].
Moim zdaniem, jedynie jasne, przejrzyste i mierzalne zdefiniowanie celw biznesowych zleceniodawcy i jednakowe ich zrozumienie przez najwaniejszych interesariuszy projektu, pozwala na rzeczywiste zrozumienie potrzeb i wymagao zleceniodawcy, uytkownikw, administratorw. Jest to, wedug mnie, wanie krytyczny czynnik sukcesu, gdy takie podejcie, w porwnaniu do analizy i projektowania zorientowanego wycznie na aspekty techniczne i zastosowanie nowych technologii, pozwala w sposb bardziej obiektywny planowad, zapewniad i oceniad jakod poszczeglnych artefaktw projektu i produktw koocowych. Miaem okazj wielokrotnie obserwowad projekty informatyczne, ktrych efektem byy systemy informatyczne speniajce wszystkie zdefiniowane na pocztku wymagania interesariuszy, kryteria akceptacji i ustalone kryteria wysokiej jakoci. Produkcja odbywaa si zgodnie z wysokimi standardami inynierii oprogramowania, a procesy byy kontrolowane. Niestety, czsto produkty te np. zamiast przyspieszyd obsug klienta zleceniodawcy opniay j, zamiast przysparzad nowych klientw odstraszay ich. Czsto

zleceniodawcy zamiast czerpad okrelone korzyci biznesowe z wprowadzenia nowej usugi szybciej ni konkurencja, tracili mnstwo czasu na dodatkowe negocjacje podczas odbioru systemu w celu uzyskania w ramach kontraktu dodatkowych funkcjonalnoci, ktre w momencie uruchomienia systemu byy ju nikomu niepotrzebne. Rozwaanie to prowadzi do stwierdzenia, e klucz do sukcesu projektu ley zarwno po stronie wykonawcy, jak i zleceniodawcy i obie organizacje powinny za cel nadrzdny przyjd osignicie korzyci biznesowych zamawiajcego dziki wdroonemu systemowi informatycznemu. Z takiego podejcia pyn dodatkowe, a moe podstawowe, wytyczne i zasady nakadane na inynieri wymagao oraz na zarzdzanie ryzykiem i ocen jakoci produktu.

Jako produktw informatycznych

Wysoka jakod produktu informatycznego jest czsto gwn kwesti, trosk i celem kadej organizacji produkujcej oprogramowanie. Mimo to, istotnym problemem w inynierii oprogramowania, zapewnianiu jakoci i zarzdzaniu jest to, e pojcie jakoci rzadko jest dobrze zdefiniowane.

Definicje jakoci wedug ekspertw

Dotychczas zaproponowano wiele definicji jakoci. Ponisze propozycje ludzi nauki naley cenid za ich ponadczasowod, uniwersalnod i lapidarnod sformuowania: Jakod to pewien stopieo doskonaoci (Platon) Jakod to istotne cechy przedmiotu wyrniajce go spord innych i stanowice o jego swoistoci pod tym wzgldem (PWN) Przewidywany stopieo jednorodnoci i niezawodnoci przy moliwie niskich kosztach i dopasowaniu do wymagao rynku (Deming) Jakod jest tym, czego brak oznacza straty dla wszystkich (Togushi) Zgodnod z wymaganiami (Crosby) Jakod to stopieo spenienia wszystkich wymagao odbiorcy (Oakland) Stopieo, w jakim uytkownik wierzy, e produkt lub usuga speniaj jego potrzeby i oczekiwania (Gitlow) Og cech i wartoci produktu decydujcych o jego zdolnoci do zaspokajania stwierdzonych lub przewidywanych potrzeb (ISO 8402) Jednak testowanie systemu informatycznego i ocena jego jakoci wg powyszych, nienamacalnych definicji s niestety bardzo trudne.

Jako systemu informatycznego

Poszukujc pojcia jakoci systemu informatycznego naley pamitad, e jakod zawsze cechuje:

powszechnod intuicyjnod kontekstowod subiektywizm Pojcie jakoci jest dynamiczne, zaley od chwili, w ktrej jest formuowany pogld na jej temat, od osoby ktra go formuuje w konkretnym miejscu, czasie i sytuacji w odniesieniu do konkretnego Systemu [7]. Aby zbudowad system informatyczny wysokiej jakoci, nie wolno nam zapomnied o w/w cechach

jakoci. Na procesy planowania, zapewniania i weryfikowania jakoci w projekcie informatycznym, musimy patrzed przez pryzmat szeroko rozumianego klienta. Rwnie opisane powyej pojcie sukcesu projektu informatycznego, rozumiane jako spenienie celw biznesowych zamawiajcego (i wykonawcy), musi byd w tym kontekcie poszerzone o warunek spenienia celw praktycznych i osobistych uytkownikw. Do tych wanych celw osobistych uytkownikw nale midzy innymi: zadowolenie z pracy, niepopenianie bdw, nie mied wraenia, e jest si gupim itp. Cele praktyczne uytkownikw najczciej s spjne z celem biznesowym organizacji zamawiajcej, zale od przeznaczenia systemu a dla przykadu moemy wymienid: bycie efektywnym pracownikiem, odnoszenie sukcesw, pokonanie konkurencji, zwikszenie sprzeday...

i wiele innych, ktrych spenienie bdzie miao duy wpyw na formuowane oceny w stosunku do systemu informatycznego [12]. Dowiedziono rwnie, i bardzo wanym elementem w procesie planowania systemu i jego jakoci jest zbudowanie szczegowego, wrcz imiennego modelu uytkownikw, odbiorcw, administratorw. Jeli ten wany element ukadanki, w ferworze walki, zostanie zagubiony, system zostanie zbudowany w taki sposb, jaki jest oczekiwany wycznie przez jego twrcw. Nie naley zapominad, e uniwersalny model uytkownika nie istnieje, a budowanie systemw dla tzw. szerokiego odbiorcy jest skazane na porak. Wci bardzo trudno sobie wyobrazid np. program do edycji plikw graficznych adresowany zarwno do wykwalifikowanych grafikw, jak i domowych uytkownikw poprawiajcych niedzielne, amatorskie zdjcia. Niewtpliwie taka prba zakooczy si frustracj jednej z wymienionych grup.

Poszukujc definicji jakoci...

Poszukujc praktycznej definicji jakoci wykonywaem badania na prbkach rnych interesariuszy projektw informatycznych (projektantw, developerw, testerw, uytkownikw). Celem badania byo wyodrbnienie atrybutw jakoci systemu informatycznego, uznawanych jako najbardziej istotne w produkcie informatycznym marzeo. Warunki wstpne przeprowadzonego badania: badanie przeprowadzono bez zapowiedzi, co miao na celu wydobycie definicji dnia codziennego, stronicej od sownikowych sformuowao, nie byo czasu do namysu, co miao na celu wydobycie definicji najbardziej spontanicznej, produkty projektw, ktrych czonkami byy osoby badane, ciesz si uznaniem na polskim i zagranicznych rynkach, a projekty zakooczone zostay sukcesem, definicja miaa byd sformuowana zwile, krtko, w kilku zdaniach aby wydobyd najwaniejsze cechy systemu informatycznego wysokiej jakoci, tred pytania Co to jest produkt informatyczny wysokiej jakoci (produkt informatyczny marzeo) ? Na podstawie wynikw powyszego badania mona jednoznacznie stwierdzid, e aby zbudowad definicj systemu jakoci systemu informatycznego trzeba j rozbid na wiele wymiarw nazywanych atrybutami jakoci. Na poniszym, przykadowym zestawieniu widad, e badana grupa osb zesp developerw, tzw. grupa sukcesu, do opisu atrybutw jakoci czciej uywaa raczej sformuowao zwizanych z uytecznoci (intuicyjnoci, atwoci obsugi) i pielgnowalnoci (moliwod np. dalszej rozbudowy systemu), ni prostych pojd zwizanych z niezawodnoci.

atrybut funkcjonalno funkcjonalno funkcjonalno niezawodno pielgnowalno pielgnowalno pielgnowalno pielgnowalno pielgnowalno pielgnowalno pielgnowalno pielgnowalno pielgnowalno uyteczno uyteczno uyteczno uyteczno uyteczno uyteczno uyteczno uyteczno wydajno

kryteria spenia wymagania chroni moj prywatno robi to co od niego oczekuj bezpieczestwo/niezawodno moduowo obsuga nie wymagajca wyczenia, atwy dostp do serwisu atwo rozbudowy przejrzysta architektura skalowalno dostpno do nowej, poprawionej wersji elastyczno nowe, na czasie technologie atwo obsugi prostota intuicyjno udokumentowany przyjazny czytelna oprawa graficzna spjno mao poziomw szybko dziaania

ilo 1 1 1 11 2 2 2 1 1 1 1 1 1 7 4 4 3 2 1 1 1 4

Tab.1 Atrybuty jakociowe systemu informatycznego najczciej wymienione przez zesp developerw

Dwie z definicji, pozyskane od uczestnikw badania wyjtkowo zasuguj na nasz uwag. Pierwsza z nich za lapidarnod sformuowania, a druga za szerokie spojrzenie i kompleksowod. Produkt informatyczny marzeo = reakcja uytkownika :-) Proces produkcji takiego oprogramowania jest przejrzysty, dobrze zdefiniowany, nadzorowany i kontrolowany. Oprogramowanie jest akceptowane i przyjmowane przez uytkownikw z przyjemnoci. Zdanie Lubi ten program jest czsto syszane od uytkownikw. Produkt jest opomiarowany, zawsze jestemy w stanie ocenid jego jakod

Model jakoci systemu informatycznego

W nawizaniu do definicji nr 2, zaproponowanej przez uczestnika badania, oraz do definicji proponowanych przez metodyki wytwarzania systemw informatycznych naley podkrelid, e, w oglnoci, zarwno wymagania, potrzeby klienta i uytkownika jak i uzgodnione metryki jakoci musz byd ( zgodnie z powyszymi rozwaaniami) rozumiane wielowymiarowo. Rational Unified Process klasyfikuje i definiuje atrybuty jakociowe wg tzw. modelu FURPS+: funkcjonalnod (Functionality) uytecznod (Usability) niezawodnod (Reliability)

wydajnod (Performance) pielgnowalnod (Supportability) S to atrybuty (czynniki jakoci) tzw. pierwszego rzdu. Wedug proponowanego przez norm ISO 9126 podejcia mog one stanowid gwne gazie budowanego na potrzeby organizacji czy projektu modelu jakoci. Rozbudowa drzewa jakoci ma na celu kwantyfikacj tych czynnikw. Kady czynnik jakoci skada si z kryteriw niszego szczebla. Kryteria te s atwiejsze do zrozumienia i zmierzenia ni czynniki, dlatego te poszczeglne metryki odnosz si do kryteriw. Drzewo przedstawia zwizki midzy czynnikami i odpowiadajcymi im kryteriami, dziki czemu moemy zmierzyd czynniki w terminach miar odpowiadajcych im kryteriw. *6+. Poniszy rysunek przedstawia przykad budowy grafu jakoci oprogramowania dla atrybutu Uytecznod.

Rysunek 1 Drzewo jakoci dla atrybutu jakociowego Uytecznod

Rozumiejc cel biznesowy odbiorcy oraz znajc profile uytkownikw koocowych systemu moemy zbudowad modele jakoci indywidualnie dla organizacji, projektu czy dla kadego z jego produktw i podproduktw.

Dopiero z modelu jakoci mog wypywad dalsze dziaania projektowe majce na celu zapewnienie jej wysokiej jakoci.

Warunki osigania wysokiej jakoci

Na podstawie powyszych rozwaao moemy przyjd, e osignicie wysokiej jakoci produktw projektu informatycznego i sukcesu projektu moliwe jest, gdy: jakoci bdziemy zarzdzad, a nie tylko j sprawdzad, odpowiednio zdefiniujemy wymagan jakod produktw majc na uwadze wystpujce ograniczenia (czas, budet, zasoby, technologie, rynek, konkurencj), wdroymy odpowiedni dla projektu model inynierii oprogramowania, procesy wytwrcze i kontroli, uzgodnimy miary kryteriw jakociowych i cele pomiarowe na poszczeglnych etapach rozwoju projektu, pozyskamy wymagania (funkcjonalne i niefunkcjonalne) szerokiego spektrum interesariuszy poprzez pryzmat celu biznesowego zleceniodawcy, projekt bdzie zgodny ze strategi biznesow i strategi rozwoju organizacji wytwrczej, bdziemy atakowad kade ryzyko zwizane z nieuzyskaniem celw biznesowych (zarwno zleceniodawcy jak i wytwrcy) najwczeniej jak to moliwe. W kolejnych artykuach w cyklu Jakod oprogramowania ustosunkuj si do wyej wymienionych, najwaniejszych obszarw zapewniania jakoci w projekcie informatycznym z praktycznego punktu widzenia.

Literatura
*1+ Anna Bobkowska: Inynieria Oprogramowania, Studium Podyplomowe Nowoczesne Metody Inynierii Oprogramowania, edycja 2006-2007 *2+ Grady Booch: Leaving Kansas IEEE Software. 15(1), Styczeo/Luty 1998 [3] Victor R. Basili: The goal question metric approach, ( Advanced Computer Studies, Department of Computer Science, University Of Maryland) *4+ John Fodeh: What's on Your Dashboard Better Software, October 2007 *5+ Janusz Grski: Zarzdzanie projektem informatycznym, Studium Podyplomowe Nowoczesne Metody Inynierii Oprogramowania, edycja 2006-2007 *6+ Janusz Grski: Inynieria oprogramowania w projekcie informatycznym, Zakad Nauczania Informatyki MIKOM, Warszawa 1999 *7+ Jerzy Kaczmarek: Metryki i zapewnianie jakoci, Studium Podyplomowe Nowoczesne Metody Inynierii Oprogramowania, edycja 2006-2007 *8+ Adam Korczowski: Zarzdzanie ryzykiem w projektach informatycznych. Teoria i praktyka, Wydawnictwo Helion 2010 *9+ Per Kroll, Philippe Kruchten: Rational Unified Process od strony praktycznej, Wydawnictwo Naukowo-

Techniczne, Warszawa 2007 *10+ Philippe Kruchten: Rational Unified Process od strony teoretycznej, Wydawnictwo NaukowoTechniczne, Warszawa 2007 *11+ Zdzisaw Szyjewski: Metodyki zarzdzania projektami informatycznymi, Wyd. PLACET, Warszawa 2004 *12+ Alan Cooper: Wariaci rzdz domem wariatw, Wydawnictwo Naukowo Techniczne, 2001