Często firmy proszą o podpisanie klauzuli poufności. Jest to pewnego rodzaju zabezpieczenie przed utratą danych, jednak czy w przypadku ich wycieku istnieje metoda na udowodnienie, że źródłem tego przecieku jest określona firma informatyczna?

Z punktu widzenia firmy informatycznej, wykorzystanie know-how zleceniodawcy jest najczęściej niemożliwe. Mimo poznania szczegółów działania firmy, nie ma ona kontaktów w branży zleceniodawcy. Mimo że stworzyła oprogramowanie, które zarządza listą dostawców i odbiorców to nie posiada danych określonych dostawców i nabywców. Firma informatyczna zna więc strukturę danych, ale nie zna samych danych. W każdym miesiącu zgłasza się wiele firm. Gdyby taka firma informatyczna chciała sprzedawać know-how zleceniodawców lub je wykorzystać przykładowo w nowej działalności, prędzej czy później wyszłoby to na jaw i sprowadziło kłopoty.

• działaniach, do których nie zostało zaprogramowane
• działaniach, do których zostało zaprogramowane lecz użytkownik nie potrafi z nich skorzystać lub robi to niewłaściwie
• działaniach, do których zostało zaprogramowane lecz błędnie
• działaniach, do których niemożliwe jest zaprogramowanie komputera (np. odczytywanie niezdarnego pisma odręcznego, w praktyce – każdego pisma odręcznego)
• działaniach, do których potrzebowałby tyle czasu, że nikt nie będzie na to czekał

Spośród nielicznych przykładów pojedynków, w których człowiek i maszyna miały wydaje się równe szanse należy wymienić pojedynki mistrza szachowego Garri Kasparowa z komputerem Deep Blue stworzonym przez IBM w latach 1996 – 1997. Choć w roku 1996 komputerowi udało się wygrać jedną partię (pierwszy raz w historii komputer wygrał wtedy z mistrzem szachowym) to ostatecznie przegrał pojedynek z mistrzem 2:4.

Komputer ulepszono i w roku 1997 rozegrano kolejne partie. Komputer wygrał cały pojedynek jednym punktem. Po przegranej Kasparow powiedział, że czasem widział w ruchach maszyny ogromną inteligencję i niezwykłą kreatywność czyli ruchy, które jak wyjaśnił nie były zrozumiane przez niego, jednak okazywały się skuteczne. Zasugerował, że maszynie mógł pomagać człowiek. Choć początkowo sugestia ta była szokująca to okazało się, że rzeczywiście kod programu był modyfikowany przez programistów w trakcie trwania rozgrywki, aby komputer nie był zaskoczony w ostatniej rozgrywce, przez co przegrywał rok wcześniej. Kasparow zażądał rewanżu, ale IBM odmówił i nie rozwijał już potem nigdy Deep Blue.

Błędy można podzielić pod wieloma względami. Najważniejszy podział to:

• Błędy krytyczne – powodują, że korzystanie z programu jest całkowicie niemożliwe. Przykładem może być sytuacja, gdy oprogramowanie na zamówienie w ogóle się nie uruchamia lub nie wykonuje poprawnie działania, które jest niezbędne dla funkcjonowania firmy
• Błędy poważne – powodują znaczne trudności w korzystaniu z części funkcji programu. Przykładem może być niewłaściwe obliczanie danych, generowanie błędów powodujące konieczność dodatkowych działań
• Błędy estetyczne – nie utrudniają korzystania z programu. Są to głównie literówki, nierówno rozmieszczone elementy GUI, błędy w funkcjonalnościach programu o małym znaczeniu.

Pod względem miejsca generowania wyróżnić możemy:

• Błędy weryfikacji danych – dane podane przez użytkownika przechodzą proces weryfikacji, mimo że są niepoprawne (np. błąd w funkcji sprawdzającej poprawność NIP)
• Błędy zapisu danych – dane są zapisane w bazie danych błędnie (np. pole NIP zapisane jest w kolumnie PESEL)
• Błędy odczytu danych – dane są niepoprawnie odczytywane z bazy danych (np. z bazy danych odczytywanych jest tylko 100 pierwszych rekordów przez oprogramowanie na zamówienie)
• Błędy przetwarzania danych – dane są źle przetwarzane (np. suma zysków firmy jest źle obliczana, mimo że dane na temat przychodów i kosztów są poprawne)
• Błędy prezentacji danych – dane są źle prezentowane użytkownikowi (np. NIP w kolumnie PESEL)

Najpoważniejsze są błędy krytyczne oraz błędy wynikające z weryfikacji czy zapisu danych. Zauważmy, że jeśli błąd nastąpi w weryfikacji danych, konsekwencją będą błędy w zapisie, odczycie, przetwarzaniu i prezentacji danych. Ważne jest, że błędy w przetwarzaniu można usunąć. Jeśli błąd zostanie wykryty, można zmienić algorytm użyty do obliczania danych a jako, że zapisane dane są właściwe, otrzymamy poprawne wyniki. W przypadku błędu w zapisie danych, często zapisanie poprawnych danych będzie niemożliwe a więc i poprawienie błędów dla danych sprzed poprawienia programu.

Każdy błąd powinien być zgłaszany twórcom oprogramowania i naprawiany. Ilość błędów jest skończona więc w przypadku intensywnego korzystania z programu, dość szybko można otrzymać wersję ich pozbawioną. Wymagane jest tu jednak ścisłe współdziałanie pomiędzy zleceniodawcą a firmą IT.

Do zgłaszania błędów pomocna może być poniższa tabela.

• Będzie działał co najmniej kilka lat więc jego koszt zakupu rozkłada się na taki okres
• Umożliwi zmniejszenie kosztów lub zwiększenie zysku przedsiębiorstwa

Ważne jest też, że niektóre funkcje programu, choć z pozoru proste w wykonaniu, powodują znaczne zwiększenie kosztów aplikacji. Warto ustalić z firmą IT, które to funkcje i jakie są możliwości manewru:

• Rezygnacja z funkcji
• Zastąpienie jej prostszą wersją
• Wdrożenie funkcji w innych modułach programu, dzięki czemu jej relatywny koszt zmniejszy się

Cena za oprogramowanie na zamówienie nie jest jedynym wyznacznikiem atrakcyjności oferty, jakie zleceniodawca otrzyma. Do innych ważnych elementów należy:

• Poziom doradztwa podczas projektowania i obsługi aplikacji

• Rodzaj licencji na program
• Długość okresu gwarancyjnego oraz elementy, jakie obejmuje
• Czas napisania aplikacji

Opis powyższych punktów należy zacząć od faktu, że właściwie stworzenie programu spełniającego choć w 90% wymagania zlecającego bez aktywnego zaangażowania firmy IT jest właściwie niemożliwe. Z naszych doświadczeń wynika, że ponad połowa zleceniodawców nie jest w stanie bez pomocy opisać więcej niż 70% funkcji, jakie powinien mieć program. Ponadto, w 90% przypadków pominięta zostaje przynajmniej jedna funkcja, bez której użytkowanie programu jest niemożliwe.

Obsługa posprzedażna powinna być szybka. W przypadku programów, ustawowy okres 14 dni nie wchodzi właściwie w grę, a już na pewno nie w przypadku problemów uniemożliwiających korzystanie z programu. Firma IT powinna też być w stanie rozwijać napisany przez siebie program, bo z biegiem czasu zawsze potrzebna jest nowa funkcjonalność.

Jeśli chodzi o rodzaj licencji to należy tu zadbać o aspekty prawne. Często spotkać się można z ograniczeniami w ilości komputerów jednocześnie używających oprogramowanie na zamówienie czy też z problemami w przypadku chęci zlecenia modyfikacji programu innej firmie niż tej, która stworzyła program.

Gwarancja powinna być dawana na jak najdłuższy okres. Powinien być w niej zapisany czas reakcji. Mogą być też ustalone zasady usuwania usterek z programu po okresie gwarancji, bo zwykle okres używania programu znacznie przewyższa okres gwarancji.

Czas napisania aplikacji zależy od licznych czynników. Zwykle liczony jest w tygodniach tak więc oczekiwanie, że ktoś napisze w kilka dni program inny niż prosty jest bezzasadne. Okres ten nie powinien być oczywiście zbyt długi.