W przedsięwzięciach informatycznych przywiązuje się różną wagę do pracy analitycznej. Wiele czynników i przyjętych kryteriów ma na to wpływ. W artykule zwrócono uwagę na tę pracę, w kontekście zapewnienia jakości rozwiązań IT. Przy czym, zagadnienie to rozpatruje się z uwzględnieniem ewaluacyjnego znaczenia rozwiązań IT w przedsiębiorstwach. Ostatecznie dokonano pewnej konfrontacji stosowanych praktyk na etapie analizy, z ich pośrednim i bezpośrednim wpływem na jakość rozwiązań IT.
Zapewne gdzieś u źródeł poruszanej w niniejszym artykule problematyki jest powszechnie znany raport organizacji „The Standish Group” pt. „The Chaos Report”, gdzie oficjalnie zauważono, że aż 31,1 % projektów informatycznych zostało anulowanych przed zakończeniem prac. Przy czym ponad połowa ogółu przedsięwzięć (52,7%) przekroczyła swój pierwotny budżet [WWW01].
Istnieje również raport z Polskiego Badania Projektów IT 2010, który odpowiada na kilka pytań, w tym – jaka część projektów IT kończy się w Polsce sukcesem. Okazuje się, że pełen sukces zaliczyło tylko 21% projektów, częściowy sukces to 46%, natomiast w kategorii porażki znalazło się aż 33%.
W interpretacji raportów należy wziąć pod uwagę bardzo istotny fakt. Otóż, współczynnikiem sukcesu są:
- zgodność rzeczywistego budżetu projektu z planowanym,
- zgodność rzeczywistego czasu trwania z planowanym,
- zgodność zrealizowanego zakresu z planowanym,
- ocena projektu dokonana przez kierownika,
- ocena satysfakcji klienta dokonana przez kierownika projektu.
U podstaw wymienionych powyżej miar leżą produkty analityczne. Mogą stanowić one punkt odniesienia w różnych aspektach przedsięwzięć, zarówno realizacji prac czy też samej oceny tych pracy. Budżet projektu, zakres prac, czas realizacji, ocena projektu czy też satysfakcja klienta mogą i powinny być budowane we współpracy z pracami analitycznymi. Budżet projektu określany jest w dużej mierze w oparciu o to, co ma być rezultatem prac/produktem. Czas i pracochłonność również jest określana w dużej mierze na podstawie tego, do czego dąży projekt. Idąc dalej, ocena zgodności zrealizowanego zakresu z planowanym kooperuje z postanowieniami zawartymi w podstawach projektu – produktach analitycznych. Ocena projektu czy też satysfakcji klienta, dokonywana przez kierownika – siłą rzeczy powinna bazować w dużej mierze na wymaganiach wobec zamawianego rozwiązania IT.
Różne definicje jakości
Powstały różne definicje i opinie na temat jakości systemów informatycznych. Podejmując się pracy związanej z definiowaniem czy też przestrzeganiem kryteriów jakości należy mieć to na uwadze. Bowiem, znajduje się w tej dziedzinie szeroki wachlarz możliwości, subiektywnych przesłanek i doświadczeń. W artykule, zostaną przytoczone powszechne definicje jakości, propagowane przez literaturę i organizacje. Będą przy tym stanowiły istotny i stabilny grunt pod dalszymi rozważaniami w niniejszym artykule.
„Jakość to zespół cech decydujący o ocenie danego wyrobu” [PRES01]
Z czego można wnioskować, że jakość jest atrybutem pewnego obiektu i można ją mierzyć i porównywać z ustalonymi standardami. Rozróżnia się: jakość projektu oraz jakość wykonania danego wyrobu (w tym przypadku systemu informatycznego). Jakość projektu dotyczy cech obiektu ustalonych przez jego projektantów. Co również oznacza, że im lepsze kryteria jakości zostaną na etapie projektowania uwzględnione, tym lepszego można spodziewać się produktu finalnego – systemu informatycznego. Warunkiem w tych rozważaniach oczywiście jest wykonanie produktu zgodnie z założeniami projektu. Jakość wykonania natomiast, odpowiada dokładności z jaką wykonano produkt i tym samym zrealizowano założenia projektu.
„Satysfakcja użytkownika = działający produkt + dobra jakość + zrealizowany budżet i harmonogram” [IEEE01]
Jakość postrzegana i równoważona z satysfakcją użytkownika. Oznacza to również, że dopóki użytkownik/ odbiorca systemu informatycznego nie będzie zadowolony, to nic innego nie ma specjalnego znaczenia.
J = R x D [PKN01]
Dokładność (D) wykonania przedmiotu technicznego porównuje się z projektem, który jest wzorcem i przybiera jeden z dwóch stanów binarnych „0” lub „1”. Racjonalność (R) wykonania przedmiotu technicznego zależy od efektywności użytkowej (E), która jest określana jako ilość zasobów zaoszczędzonych w działaniu dzięki instrumentalizacji przypadających na jednostkę nakładów poniesionych na wyprodukowanie i eksploatowanie przedmiotu technicznego. Instrumentalizacja to zastosowanie przedmiotu technicznego w pracy człowieka. Ilość zasobów zaoszczędzonych dzięki instrumentalizacji (efekt użytkowy) należy rozumieć jako różnicę między ilością zasobów zużywanych przed jego instrumentalizacją a ilością zasobów zużywanych w działaniu po jego instrumentalizacji. Dzieląc efekt użytkowy przez sumę nakładów na przedmiot techniczny, otrzymujemy efektywność użytkową.
W powyższych rozważaniach uznaje się wariant za ekonomiczny w sensie prakseologicznym, jeśli E>1. Stąd wynika, że racjonalność R=1 dla E>1 lub R=0 dla E<1; zatem spełnianie wymagań jakościowych dotyczy zarówno warunków dokładności wykonania, jak i racjonalności projektu (D=1 i R=1). Z definicji również wynika, że każde działanie nastawione na osiągnięcie pewnego celu musi być logiczne, przemyślane i musi odznaczać się dbałością o szczegóły. Racjonalność wymusza gruntowną analizę potrzeb – poszukiwanie odpowiedzi na pytania: o odbiorcę, o uwarunkowanie ekonomiczne, o innowacyjność. Przykładowym pytaniem byłoby – do jakiego klienta kieruję produkt i jakie są jego potrzeby ?”
Powyższe definicje informują o silnym związku efektów z analizy biznesowej w odniesieniu do jakości wytwarzanego systemu. Interpretując w dalszej części artykuł, warto zauważyć i przywołać cytat:
„Zapewnienie jakości oprogramowania
to przełożenie ogólnych zasad zarządzania jakością
na możliwe do praktycznego zastosowania
techniki Inżynierii Oprogramowania” [QACS01]
Przy czym, sformułowanie „możliwe do praktycznego zastosowania technikii Inżynierii Oprogramowania” stwarza bardzo wiele możliwości i jednocześnie niejednoznaczności. Zwracam tym samym uwagę, że z biegiem czasu przybywa technik Inżynierii Oprogramowania co tym bardziej utrudnia precyzyjny wybór tych właściwych w konkretnym przedsięwzięciu IT.
Wracając jednak do podstawowej kwestii, zapewnienie jakości związane jest z takimi obszarami prac, jak: [PRES01]
- jasnego sformułowania wymagań,
- wytwarzania oprogramowania w zgodzie z ustalonnymi standardami/ normami,
- uwzględniania oczywistych i powszechnych wytycznych stojących za oczekiwaniami użytkowników, które nie koniecznie mogły być artykułowane przez zamawiającego produkt.
Czynności związane z zapewnieniem jakości, można również podzielić na dwie grupy wykonawców:
- zespół wytwórczy,
- zespół kontroli jakości.
Powyżej wymienione obszary prac i zagadnień są przedmiotem rozważań nie tylko w odrębnych artykułach czy też książkach ale szerokimi dziedzinami wiedzy. Dlatego też, skupiam się w niniejszym artykule nad pierwszym i podstawowym obszarem prac, mianowicie „jasnym sformułowaniem wymagań”.
W następnej części artykułu przedstawię jak wygląda analiza biznesowa w firmach.
Źródła:
- „Zastosowanie warsztatu analizy biznesowej w celu zapewnienia jakości projektów IT”, Artur Machura, Organization of Software Engineers
- [WWW01] The Chaos Report – http://www.projectsmart.co.uk/docs/chaos-report.pdf, The Standish Group 1995
- [PRES01] Pressman Roger: Praktyczne podejście do Inżynierii Oprogramowania, WNT 2004
- [IEEE01] R., L. Glass: Defending Quality Intuitively, IEEE Software, 1998
- [foto] http://www.flickr.com/photos/thomashawk/221827536/
