Skoro taka jest rzeczywistość, to jak można mierzyć jakość oprogramowania lub systemu informatycznego, jak ocenić jakość wykonanego zobowiązania?

Transkrypt

1 Pojęcie należytej staranności w kontekście analizy wykonania zobowiązań dotyczących oprogramowania komputerowego i wdrażania systemów informatycznych próba definicji Zagadnienie należytej staranności w wykonywaniu zobowiązań ma bardzo bogatą literaturę. Jednakże praktyczne określenie, jaki sposób działania wykonawcy oprogramowania komputerowego lub systemu informatycznego można uznać za wykonanie zobowiązania z dołożeniem należytej staranności, nie jest już takie oczywiste i nie zostało jeszcze opracowane. Ocena jakości wykonania zobowiązań dotyczących oprogramowania komputerowego i wdrażania systemów informatycznych, z jednej strony wydaje się bardzo trudna, z drugiej bardzo prosta. Teoretycznie można przyjąć, że wystarczy przed odbiorem wykonać testy akceptacyjne (User Acceptance Tests - UAT, inaczej zwane Business Acceptance Tests BAT) i jeśli system lub oprogramowanie działa poprawnie to znaczy, że zamawiający otrzymuje dobry produkt odpowiedniej jakości. Dodatkowo należy zbadać dokumentację i sprawdzić, czy wszystkie licencje i inne umowy wynikające z prawa autorskiego, dotyczące ochrony patentów itp. zostały odpowiednio zawarte, a prawa wynikające z tych umów przeniesione na odpowiednie podmioty. Jeśli testy wypadły pomyślnie, a umowy zostały sporządzone prawidłowo możemy przyjąć, że zobowiązanie zostało wykonane należycie. O ile stwierdzenie istnienia lub nieistnienia wad prawnych produktu (na potrzeby niniejszego artykułu będziemy używać pojęcia produkt ), jakim jest oprogramowanie lub system informatyczny, wydaje się w miarę proste i możliwe do przeprowadzenia, o tyle stwierdzenie istnienia lub nie wad fizycznych oprogramowania nie jest rzeczą oczywistą. Jeśli bowiem oprogramowanie przeszło pomyślnie testy użytkownika, nie oznacza to, że będzie działało poprawnie i że nie ma wad fizycznych. Rozpatrywane tu zagadnienia należytej staranności w wykonywaniu zobowiązań dotyczących oprogramowania zostaną celowo zawężone do rozpatrywania jedynie kwestii wad fizycznych produktu, jakim jest oprogramowanie lub system informatyczny. W wyniku wykonania zobowiązania dotyczącego oprogramowania komputerowego lub systemu informatycznego, zamawiający otrzymuje ZAWSZE produkt, który ma wady fizyczne, zarówno ukryte jak i jawne, a wykonawca zobowiązania ma świadomość istnienia tych wad, a na pewno powinien mieć tę świadomość. Jeśli jej nie ma lub zapewnia zamawiającego, że produkt nie ma wad, świadczy to bardzo źle o jego profesjonalizmie. Z reguły wykonawca nie informuje zamawiającego o możliwości istnienia wad, ponieważ jest to dla niego rzecz oczywista i wydaje mu się, że zamawiający również o tym wie, ponieważ wiedzieć powinien jako, że jest to fakt powszechnie znany i nie wymagający dowodu. Pierwszą myślą, jaka w takiej sytuacji nasuwa się prawnikowi jest zażądanie dostarczenia produktu bez wad, usunięcia wad. Jednakże wykonawca nie będzie mógł ich usunąć, ponieważ nie wie ani jakie te wady są, ani gdzie w systemie lub programie się znajdują. Myślenie o oprogramowaniu bez wad przeszło zupełnie do historii na początku lat osiemdziesiątych ubiegłego stulecia. Wraz z rozpowszechnianiem się użycia komputerów i wzrastającym zapotrzebowaniem na nowe, powszechnie używane programy, zaczęto w szybkim tempie wytwarzać oprogramowanie tanie, powszechnie dostępne. Tanie oprogramowanie, szybko wytwarzane i powszechna dostępność te czynniki powodowały, że trzeba było obniżać koszty, nie było czasu na długie testowanie wszystkiego, konkurencja wymuszała

2 szybkie zmiany, Bill Gates wchodził coraz śmielej na rynek ze swoimi produktami. Wszyscy doszli do wniosku, że najwyższa jakość, 100% niezawodność w programach dla komputerów domowych i gier nie jest konieczna. Wtedy to też powstało pojęcie good enough software - oprogramowanie wystarczająco dobre. Później tempo zmian technologicznych i rynkowych, zapotrzebowanie na coraz to nowe programy i coraz bardziej złożone systemy, zmusiło firmy wytwarzające oprogramowanie do pracy w bardzo szybkim tempie, do zatrudniania wielu nowych programistów. Zamiast małych grup kilku programistów współpracujących ze sobą latami, powstały wielkie grupy anonimowych koderów, siedzących przy swoich komputerach i w różnych częściach świata piszących swoje linie kodu, dla kilku projektów jednocześnie. Szybko powstają skomplikowane systemy, ale prawdopodobieństwo wystąpienia błędów rośnie. Skoro taka jest rzeczywistość, to jak można mierzyć jakość oprogramowania lub systemu informatycznego, jak ocenić jakość wykonanego zobowiązania? Czy jest jakaś na to rada i co można zrobić, aby otrzymać w końcu produkt wysokiej jakości? Jakie kroki należy podjąć, jakie środki prawne można zastosować? Nie ma oprogramowania komputerowego ani systemu informatycznego bez defektów. Każde oprogramowanie zawiera defekty pomimo wielokrotnego sprawdzania i testowania. W tym miejscu należałoby ujednolicić pojęcia nakładając na siebie siatkę pojęciową z zakresu inżynierii oprogramowania i prawa. Przyjęte przez prawników i używane na co dzień pojęcie: umowa wdrożeniowa na system IT lub umowa o wdrożenie systemu informatycznego jest bardzo mylące dla inżynierów oprogramowania. W inżynieria oprogramowania pojęcia wdrożenie używa się jedynie na określenie ostatniej tylko fazy projektu informatycznego polegającej na instalacji i uruchomieniu u klienta zbudowanego systemu informatycznego. Szerszym pojęciem jest pojęcie projektu informatycznego. W terminologii inżynierii oprogramowania projekt informatyczny składa się z następujących faz: - pozyskiwania, analizy i specyfikacji wymagań - projektowania architektury systemu - implementacji (programowania) - integracji (scalania) - testowania na wielu poziomach - wdrożenia właściwego, czyli zainstalowania i uruchomienia systemu u klienta Używając pojęć z zakresu inżynierii oprogramowania należałoby stwierdzić, że przedmiotem umowy jest projekt informatyczny, czyli lepiej byłoby może używać nazwy umowa o wykonanie projektu informatycznego lub umowa o projekt informatyczny. Byłaby ona mniej myląca dla jednej ze stron umowy wykonawcy, dla zamawiającego nie ma to praktycznie znaczenia. Rozpatrując problem wad fizycznych produktu jakim jest oprogramowanie lub system informatyczny, konieczne jest precyzyjne ustalenie zakresu znaczenia pojęć używanych w inżynierii oprogramowania i w prawie. Inżynieria oprogramowania posługuje się następującymi pojęciami: 1) błąd działanie ludzkie, pomyłka w trakcie tworzenia oprogramowania

3 2) defekt (potocznie zwany z ang. bug) jest wynikiem błędu ludzkiego, jest to zła część kodu, błędna instrukcja w systemie itp. 3) awaria jest wynikiem defektu, z awarią mamy do czynienia, gdy program nie działa lub działa niepoprawnie. Czy jednak każdy defekt można uznać za wadę w sensie prawnym? Otóż wydaje, się, że nie. Istnieje w kodzie wiele defektów, które nigdy nie zostaną wykryte, dotyczą bowiem tych elementów oprogramowania, które nie mają bezpośredniego wpływu na codzienne użytkowanie systemu, nigdy podczas pracy systemu się nie ujawnią lub mogą ujawnić się dopiero w ekstremalnych warunkach (np. w systemie bankowym defekt doprowadzi do awarii przy temperaturze otoczenia 15 stopni C, a system projektowany jest do pracy w budynku w temperaturze pokojowej ok stopni C). Wydaje się, że jako wady fizyczne systemu lub oprogramowania prawnik zakwalifikuje tylko te defekty, które mogą spowodować awarię. Mają one bezpośredni wpływ na funkcjonalność systemu, stanowią o użytkowych walorach systemu, a co za tym idzie wpływają na gospodarcze interesy zamawiającego. Przedstawione wyżej stwierdzenie dotyczy wszystkich systemów i programów komputerowych, tzn. każdy system i każde oprogramowania będzie miało wady fizyczne. Będą to zarówno wady jawne jak i ukryte. Tu pojawia się kolejny problem terminologiczny - co to są wady jawne, które defekty można uznać za wady ukryte, a które za wady jawne. Wydaje się na pierwszy rzut oka, że wada jawna to taka wada, którą zamawiający jest w stanie wykryć i zauważyć podczas zwykłego użytkowania produktu. Ale co to oznacza w praktyce? Jeśli po włączeniu komputera jakaś aplikacja nie działa to jest to doskonały przykład wady jawnej, ale już przypadek, kiedy to samo zjawisko występuje np. raz w roku, albo przy każdym setnym lub tysięcznym użyciu nie jest taki oczywisty. Wada, którą użytkownik zauważył po trzech dniach użytkowania systemu (czyli dla niego wada jawna) mogła być wcześniej nie zauważona przez wykonawcę i testerów (dla nich będzie to wada ukryta). Czy będziemy ją uważali za wadę jawną czy ukrytą? Wiele jest takich pytań. Odpowiedź na nie wymaga dogłębnej analizy problemu i współpracy interdyscyplinarnej specjalistów z obu dziedzin: prawa i inżynierii oprogramowania. Nie można jednak ignorować rzeczywistości i poruszać się wyłącznie w wyidealizowanym świecie teorii. Biznes wymaga praktycznych rozwiązań na co dzień. W przypadku zobowiązań dotyczących innych dziedzin o wiele łatwiej jest znaleźć mierniki jakości produktów, zabezpieczyć umownie lub ustawowo interesy obu stron kontraktu. Ponieważ każde oprogramowanie i każdy system informatyczny ma wady, więc o jakości produktu, o ocenie sposobu wykonania zobowiązań dotyczących tworzenia i dostarczania oprogramowania lub systemu informatycznego, decydować będzie raczej ocena, czy zachowano lub nie należytą staranność przy jego wytwarzaniu i wdrażaniu. Czyli, czy zrobiono wszystko żeby tych wad było jak najmniej? Na czym jednak będzie polegać zachowanie należytej staranności w przypadku konkretnego oprogramowania lub systemu informatycznego nie jest już sprawą oczywistą. Kiedy można uznać, że wykonanie zobowiązania dotyczącego oprogramowania lub systemu informatycznego odpowiada wymaganiom z art. 355 kc? Czy same wyniki testów mogą być miernikiem jakości oprogramowania? Jak dogłębnie należy testować oprogramowanie i kto o tym powinien decydować? Jak udowodnić, że twórca oprogramowania lub systemu informatycznego dołożył należytej staranności?

4 Kiedy z czystym sumieniem można przestać testować, aby nie ponosić odpowiedzialności za niedoskonałości programu? Dla każdego oprogramowania lub systemu odpowiedź będzie brzmiała różnie, w zależności od jego złożoności oraz przeznaczenia. Istnieją jednak pewne podstawowe elementy wspólne dla oceny sposobu wykonywania zobowiązania. Po pierwsze: Żądając od wykonawcy poprawnego wykonania zobowiązania, trzeba jasno i bardzo precyzyjnie określić wymagania. Na tym początkowym etapie tworzenia oprogramowania komputerowego lub systemu informatycznego, współpraca zamawiającego i wykonawcy jest konieczna i bardzo istotna. Obie strony muszą dołożyć należytej staranności we współdziałaniu. Jeśli zamawiającemu zależy na wysokiej jakości produktu, musi określić swoje wymagania bardzo szczegółowo, precyzyjnie i jednoznacznie, przyjmując, że nie ma rzeczy oczywistych. To, co dla jednego specjalisty jest oczywistością, dla programisty może być zupełnie niezrozumiałe. Dział inżynierii oprogramowania zajmujący się zagadnieniami wymagań, nazywa się inżynierią wymagań, a dokument opisujący wymagania, stanowiący podstawę pracy dla architektów oprogramowania komputerowego lub systemu informatycznego i programistów, nazywa się zwykle specyfikacją wymagań. Cennym elementem ułatwiającym rozstrzyganie sporów dotyczących jakości produktu końcowego, może być włączenie specyfikacji wymagań do umowy. Po drugie: Na etapie tworzenia oprogramowania komputerowego lub systemu informatycznego, zamawiający ma najmniejsze możliwości sprawdzenia i oceny sposobu wykonywania zobowiązania, jednakże istnieją pewne normy, zespoły dobrych praktyk, przyjęte i opisane metody oraz procedury postępowania, dotyczące procesów inżynierii oprogramowania. Przestrzeganie tych zasad lub norm, powołanie się na nie w umowie lub ew. w protokołach odbioru stanowi element zapewnienia wysokiej jakości produktu i może być uznane za przejaw wykazywania należytej staranności. Po trzecie: Weryfikowanie jakości produktu w trakcie jego tworzenia i produktu końcowego, czyli testowanie. Co, kiedy i jak testować? Dla każdego oprogramowania lub systemu odpowiedź będzie brzmiała różnie, w zależności od jego złożoności oraz przeznaczenia. Nie jest konieczne wykonywanie bardzo dogłębnego testowania na przykład pełnej analizy statycznej kodu źródłowego - w przypadku małego systemu do zarządzania rozgrywkami szkolnej ligi siatkówki. Tu wystąpienie ewentualnej awarii systemu jest być może kłopotliwe, ale nie bardzo groźne, a szkolnej ligii siatkówki nie stać na bardzo drogi system, chyba, ze wykonają go za darmo studenci informatyki w ramach ćwiczeń programowych. Niestety, wyższe uczelnie na wydziałach informatyki zaniedbują w programach nauczanie inżynierii jakości, a szczególnie zagadnienia testowania traktują marginalnie. A przecież w przypadku nawet małego programu mającego zastosowanie np. w medycynie testowania nigdy dość, tu najmniejszy nawet błąd może spowodować śmierć wielu osób.

5 W przypadku testowania oprogramowania lub systemu należy zawsze znaleźć złoty środek pomiędzy ryzykiem wystąpienia awarii, kosztami i czasem poświęconym testowaniu, tak, aby w końcowym efekcie otrzymać produkt właściwej jakości: niezawodny na miarę potrzeb. Sporządzając umowę, dobrze jest zawrzeć w niej ustalenia co do sposobu testowania oprogramowania komputerowego lub systemu informatycznego, na jakich etapach budowania projektu będą one wykonywane oraz ew. zażądać dołączenia raportów testowych do dokumentacji odbioru produktu. Zamawiający musi mieć świadomość, ze każde dokonanie zmian na poszczególnych etapach tworzenia oprogramowania komputerowego lub systemu informatycznego zwiększa ryzyko zaistnienia defektów, wymusza dodatkowe testy i wydłuża czas wykonania zobowiązania. Dlatego też chcąc zapewnić sobie wysoką jakość produktu końcowego, należy na etapach wstępnych poświęcić więcej uwagi i pracy przygotowaniom. Koszty wydane na przygotowania zwracają się wielokrotnie w postaci niezawodności i jakości oprogramowania lub systemu. Nie można też żądać rzeczy niemożliwych: np. zbudowania i wdrożenia systemu w miesiąc, bez podania specyfikacji wymagań, dokonując zmian co trzy dni, zostawiając dwa dni na testowanie! Przedstawione powyżej sugestie działań ze strony zamawiającego jasno wskazują, że powinien on zarówno na etapie sporządzania umowy jak i odbioru oraz oceny oprogramowania komputerowego lub systemu informatycznego korzystać z pomocy profesjonalisty. Wydaje się, że nie da się tego uniknąć. Wiedza powszechnie dostępna nieprofesjonalistom zupełnie nie wystarcza do oceny prawidłowości całego procesu, konsekwencje zaniedbań mogą być dla zamawiającego bardzo poważne. Bez wątpienia podnosi to koszty całego projektu informatycznego, ale w konsekwencji podnosi jakość produktu, a jakość zawsze się opłaca. Podsumowując trzeba stwierdzić, że trudno jest jednoznacznie określić, czym jest należyta staranność w wykonaniu zobowiązania, którego przedmiotem jest oprogramowanie komputerowe lub projekt informatyczny. Dla każdego projektu, należałoby przyjąć inne kryteria, mając na względzie jego gospodarcze przeznaczenie. Zawsze jednak należy domagać się zachowania obowiązujących standardów i dobrych praktyk oraz zachować zdrowy rozsądek, dla którego jeszcze nie wynaleziono miary. Magdalena Kowalska Absolwentka Wydziału Prawa i Administracji Uniwersytetu Warszawskiego oraz Szkoły Głównej Handlowej - studium podyplomowego Zarządzanie biznesem międzynarodowym W przeszłości pracownik naukowy Instytutu Nauk Prawnych Polskiej Akademii Nauk i nauczyciel akademicki w Szkole Głównej Gospodarstwa Wiejskiego W swojej karierze zawodowej była także urzędnikiem centralnej administracji państwowej, między innymi wice-dyrektorem gabinetu ministra

6 Ma doświadczenie w dziedzinie zarządzania projektami, kierowała między innymi częścią projektu prywatyzacyjnego NFI. Specjalistka we wdrażaniu programów pomocowych UE Od 12 lat doradca inwestorów zagranicznych w Polsce w sektorze poligraficznym, paliwowym, zarządzaniu strefami wolnocłowymi Specjalista w dziedzinie zarządzania, zajmowała się postępowaniami naprawczymi i restrukturyzacją podmiotów gospodarczych sektorze MSP, przedsiębiorca Prawdopodobnie, jako jedyny prawnik w Polsce - zdała egzamin i zdobyła międzynarodowy certyfikat w zakresie testowania oprogramowania komputerowego wydawany przez International Software Testing Qualification Board Zna język francuski, włoski, angielski i rosyjski Od 1992 roku jest prezesem zarządu Fundacji Św. Marka na Rzecz Osób Niepełnosprawnych i Potrzebujących Pomocy