Jak we właściwy sposób odbierać kody źródłowe, aby uniknąć poważnych problemów z rozwojem systemu?
Czy wiesz jak poprawnie odbierać kody źródłowe od wykonawcy? Nasza praktyka pokazuje, że wiele firm popełnia na tym etapie błędy, które w przyszłości skutecznie uniemożliwią rozbudowę systemu. Jak się przed nimi uchronić?

Z artykułu dowiesz się:

• jakie błędy popełniają firmy odbierając kody źródłowe
• jakie są konsekwencje posiadania niewłaściwych kodów
• z jakimi problemami mieli do czynienia nasi klienci
• jak prawidłowo przejmować kody wraz z dokumentacją

Najczęstsze błędy

W wielu przypadkach klient nie zatrudnia programistów, którzy mogliby sprawdzić stan przekazanych danych. Dla niego najważniejszym zagadnieniem jest test działania systemu, natomiast sprawdzając kody, upewnia się jedynie… czy je otrzymał. Nie weryfikuje ich i zakłada, że są zgodne z systemem uruchomionym przez wykonawcę. Co więcej, często odbiera je tylko po zakończeniu głównej części projektu i nie uzupełnia ich po późniejszych modyfikacjach.

Dopóki klient regularnie współpracuje z wykonawcą systemu, dopóty wszystko działa jak należy. Problem pojawia się, gdy ktoś inny przejmuje obsługę programu. Czy ja napisałem problem? Pojawia się masa problemów i to w najgorszym możliwym momencie!

Typowe konsekwencje niewłaściwego odbioru kodów:

• systemu nie da się skompilować ze względu na braki w dokumentacji lub w kodach,
• po wykonaniu kompilacji okazuje się, że brakuje kodów do poszczególnych modułów,
• systemu nie da się zainstalować „od zera” ze względu na brakujące komponenty,
• system uruchomiony na serwerze testowym działa inaczej niż ten dostarczony przez wykonawcę.

Klienci w tej sytuacji kontaktują się z wykonawcą programu i to często załatwia sprawę. Zdarza się jednak, że wykonawca nie przechowywał kodów ani dokumentacji, bo ich współpraca zakończyła się dawno temu. Nierzadko jest tak, że osoby odpowiedzialne za projekt już nie pracują w danej firmie. Bez względu na przyczyny, brak pomocy ze strony twórcy systemu oznacza kłopoty dla właściciela.

Tak to wygląda w praktyce – przykłady problemów naszych klientów

Przykład pierwszy – mnóstwo zmarnowanego czasu

U jednego z klientów przejmowaliśmy opiekę nad systemem po innym wykonawcy. System składał się z kilkunastu dużych modułów i całość stanowiła dosyć rozbudowany program. Wraz z dokumentacją otrzymaliśmy paczkę kodów źródłowych i teoretycznie wszystko powinno pójść gładko. Zaczęliśmy od sprawdzenia kodów i już na starcie trafiliśmy na przeszkodę. Programu nie dało się uruchomić na serwerze testowym.

Poświęciliśmy miesiąc na intensywną komunikację z klientem i wykonawcą i w jej wyniku otrzymaliśmy właściwe kody. „Tym razem się udało” – pomyśleliśmy. Niestety, niedługo potem odkryliśmy, że nadal nie dysponujemy kodami do wszystkich składników. Ich brak, mimo działającego systemu, uniemożliwiał nam jego rozwój. Uzyskanie brakujących kodów zajęło nam następne kilka tygodni. Zmarnowaliśmy mnóstwo czasu uruchomienie i uzyskanie pełnego dostępu do programu. Czasu, który mogliśmy poświęcić na właściwą pracę nad obsługą i rozwojem.

Przykład drugi – mały problem, duże konsekwencje

Kilka lat temu, nasz obecny klient zamówił w pewnej firmie system do przetwarzania skanów dokumentów. Przez następne lata system pracował stabilnie i nie było z nim problemów. Następnie zmieniło się prawo, a wraz z nim należało lekko zmodyfikować system. Niestety, wykonawca systemu nie był zainteresowany współpracą – być może nie dysponował już ani dokumentacją, ani ludźmi, którzy tworzyli ten projekt. Wtedy klient, szukając innego wykonawcy, zgłosił się do nas.

Po wstępnych rozmowach ustaliliśmy, że:

• klient posiadał kody źródłowe, ale tylko do pierwszej wersji systemu,
• system korzystał z zewnętrznej biblioteki OCR, do której klient nie miał licencji programistycznej,
• aby przeprowadzić zmiany, musielibyśmy wykupić analogiczną licencję, a jej koszt stanowił znaczny procent wartości projektu.

Tutaj nie było happy endu. Mimo iż modernizacja systemu była niewielka, powyższe problemy skutecznie ją uniemożliwiły. W efekcie klient nie miał innego wyjścia niż zamówić nowy system.

Zatem, jak prawidłowo odbierać kody?

Poprawna procedura odbioru kodów nie jest skomplikowana, ale należy jej ściśle przestrzegać. Stosuj ją nie tylko przy odbiorze głównej części systemu, ale także przy każdej modyfikacji programu.

Odbierając system:

• dokładnie skontroluj kompletność kodów źródłowych z uwzględnieniem wszystkich modułów i poprawek,
• zapoznaj się i sprawdź kompletność instrukcji instalacji systemu,
• zainstaluj całość „od zera” na nowym serwerze korzystając z otrzymanych kodów,
• testy działania przeprowadzaj na systemie uruchomionym z kodów źródłowych.

Minimalny wariant bezpieczeństwa zakłada, że powyższą procedurę powinien przeprowadzić wykonawca w obecności zamawiającego. Jest to wygodna opcja, szczególnie dla firm bez własnego zaplecza IT. Nie gwarantuje jednak 100% pewności, że w przyszłości wszystko będzie działać, jak należy.

W optymalnym wariancie wykonawca przekazuje paczkę kodów i dokumentacji klientowi. Ten z pomocą własnego zespołu lub zatrudniając zewnętrzną firmę, przeprowadza całą procedurę na własną rękę, bez udziału wykonawcy. Dzięki temu klient może dokładnie zweryfikować kompletność kodów i poprawność działania systemu. Ewentualne braki i usterki zostaną naprawione, a w przyszłości nie będzie problemów z modyfikacją oprogramowania przez inne ekipy programistów. Koszt takiego rozwiązania to zaledwie mały procent wartości zamówienia, ale skutecznie minimalizuje ryzyko strat w przyszłości.

Bądź skrupulatny

Systemy informatyczne pisane na zamówienie, to unikalne oprogramowanie, do którego obsługi niezbędna jest kompletna dokumentacja i aktualne kody źródłowe. Dlatego tym bardziej zachęcamy Cię do wnikliwej analizy otrzymywanych kodów i postępowaniu według zalecanej procedury, jaką przedstawiliśmy w tym artykule. Dzięki niej Twoja firma nigdy nie doświadczy problemów z rozwojem systemu.