W tym odcinku przedstawiam garść porad, które pomogą Ci lepiej zweryfikować oprogramowanie dedykowane, z którego korzystasz w swojej organizacji.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 30, „6 zasad dobrego audytu oprogramowania dedykowanego”. W odcinku 24 wspominałem o utrzymywaniu oprogramowania legacy różnego rodzaju, zarówno gotowego, jak i dedykowanego. Niniejszy odcinek stanowi, można powiedzieć, kontynuację tamtego odcinka, jest to taka część druga, bo po czasie uznałem, że warto by uzbroić Cię, słuchaczu, słuchaczko, w wiedzę na temat tego, o czym warto pamiętać, gdy zechcesz zweryfikować stan posiadanego oprogramowania dedykowanego, zarówno pod kątem bieżącej sytuacji jak i możliwości rozwoju. Zaznaczę tutaj od razu, że skupiam się stricte na audycie oprogramowania dedykowanego, to znaczy, można powiedzieć, środowiska IT można audytować na wiele różnych sposobów, wiadomo – audyt związany z RODO, cyberbezpieczeństwo, różnego rodzaju tematy związane z ISO, natomiast mimo wszystko, ja tutaj skupiam się na tym, że jest jakieś oprogramowanie dedykowane, chcesz je zweryfikować i teraz może się okazać, że na przykład to oprogramowanie warto zbadać również pod kątem bezpieczeństwa, no, jest wiele takich aspektów technicznych, pod jakimi można by oprogramowanie zbadać. Ja nie wykluczam, że w przyszłości też tym się zajmę, natomiast dzisiaj chcę się skupić na oprogramowaniu jako takim. Żeby nie robić więcej spojlerów, to za chwilę po prostu przejdziemy do zasadniczego tematu, natomiast na pewno warto też, zwłaszcza, jeżeli nie wiesz, co w trawie piszczy u ciebie, w organizacji, warto też rozważyć jakieś inne formy, rodzaje audytów informatycznych, chociażby właśnie pod kątem cyberbezpieczeństwa czy RODO.

W ramach tego odcinka przejdziemy przez takie 6 zasad, czy nawet bardziej należałoby powiedzieć, 6 aspektów, pod jakimi warto przeanalizować swoje oprogramowanie i paradoksalnie, nie będą to tylko, czy nawet w większości, tematy techniczne. Zaczniemy od kwestii może pozornie właśnie mniej istotniej, bo wydaje się, że najważniejsze w audycie oprogramowanie jest określenie stanu technicznego, natomiast zaczniemy od tak naprawdę rzeczy strategicznej, czyli sytuacji prawnej oprogramowania, z którego korzystasz, korzystała twoja organizacja. Standardowo, żeby nie było, wspomnę o tym, że nie jestem prawnikiem, więc w razie wątpliwości warto skontaktować się z jakaś kancelarią, która specjalizuje się właśnie w tematach najlepiej związanych z IT, natomiast po tym disclaimerze mogę przejść już do rzeczy.

Podstawowe pytanie brzmi: jakim prawem, na jakiej podstawie korzystasz z danego oprogramowania? Czy posiadasz może do niego prawa majątkowe? Czy została udzielona jakaś forma licencji? Możliwości tak naprawdę w szczegółach jest wiele, natomiast warto zdać sobie sprawę, że sam fakt, że dysponujesz oprogramowaniem i dokonałeś, dokonałaś jakiejś płatności za nie, to trochę za mało. Jeżeli oprogramowanie zostało zakupione z zewnątrz, to znaczy była jakaś firma, która dostarczyła oprogramowanie i sobie z niego po prostu korzystasz, to, no, najlepiej odwołać się do jakichś umów, regulaminów, dokumentów, które były dostarczone wraz z oprogramowaniem, czy przed wykonaniem oprogramowania z reguły jeśli chodzi o umowy związane z realizacją, wykonaniem takiego oprogramowania i teraz – jeżeli przy dogadywanie się z software housem, czy inną podobną firmą, jest sekcja o przekazaniu praw majątkowych, praw autorskich, to prawdopodobnie jest w porządku. W takiej sekcji z reguły pojawia się wiele zapisów właśnie o przekazaniu praw do użytkowania, do dalszego dysponowania dziełem, czyli właśnie oprogramowaniem w tym przypadku. Nie będę wchodził teraz bardzo w szczegóły tych zapisów, bo sam też w bardziej skompilowanych sytuacjach konsultuję się z prawnikami, ale taka sekcja na ogół świadczy o tym, że jest to temat zagospodarowany. Czasem jednakże zdarza się, że oprogramowanie jest wytworzone wewnątrz firmy, że po prostu twoi pracownicy nad tym oprogramowaniem pracowali. I tutaj, tak naprawdę, jest ważna rzecz – jeżeli masz po prostu programistów, którzy w swoim zakresie obowiązków mają realizację oprogramowania, to tutaj przy umowie o pracę sprawa jest prosta, programiści programują, wytwarzają to oprogramowanie, to oprogramowanie jest twoje. Natomiast zdarza się, i to są sytuacje absolutnie z życia wzięte – może w ostatnich latach trochę rzadziej, ale zwłaszcza w większych firmach, czasami ktoś na przykład pełni rolę zupełnie inną, nie programistyczną, jest zatrudniany w innym charakterze, ale na przykład rozwija się, uczy się – na przykład często spotykałem się z takimi sytuacjami, że moi studenci, ci ze studiów zaocznych, weekendowych, pracowali w jakimś tam charakterze na co dzień, ale myśleli o karierze później już informatyków, programistów i jeszcze w ramach nauki wykonywali jakieś oprogramowanie dla swoich pracodawców. I tutaj jest ważna rzecz, bo jeżeli taki pracownik jest zatrudniony w zupełnie innym charakterze, to kwestia praw do oprogramowania jest dyskusyjna, to znaczy tutaj nie podejmuje się jednoznacznego rozstrzygnięcia, natomiast, jakby tutaj pojawia się taki zasadniczy problem, że jeżeli ktoś nie ma w obowiązkach wpisane, że tworzy oprogramowanie i nawet je wytworzył, to prawa niekoniecznie z automatu, można powiedzieć, będą przekazane. Wiadomo, że tego rodzaju spory, jeżeli dochodzi do jakichś sporów, to wchodzi już taka dyskusja w niuanse, natomiast to na pewno nie jest łatwa sytuacja. Zdecydowanie lepiej, jeżeli na przykład chcesz dogadać się z pracownikiem, który właśnie robi coś innego w firmie, ale chce wytworzyć oprogramowanie, bo umie, na przykład, to po prostu podpisać dodatkową umowę czy zlecenie, dzieła teraz są trochę coraz bardziej obostrzone, ale jeżeli to jest jednorazowe dzieło, to… chociaż tu lepiej też się konsultować. Natomiast w każdym razie, dodatkowa umowa na takie oprogramowanie, ważne, żeby właśnie też wtedy te prawa autorskie najlepiej przekazać, żeby nie było właśnie bałaganu z tym związanego. Oczywiście nie trzeba mieć autorskich praw majątkowych, aby móc swobodnie korzystać z oprogramowania i wiele firm software house’owych decyduje się na udzielanie dość takich permisywnych, czyli można powiedzieć, liberalnych licencji, trochę na zasadzie znanej, używając słów Jurka Owsiaka, „róbta, co chceta”, gdzie w zasadzie taka firma otrzymuje możliwość rozwoju oprogramowania w sposób swobodny, może robić z nim, co chce. Może z wyjątkiem jakiegoś nieograniczonego rozdawania czy sprzedaży dalej, jakby z perspektywy software housu, przecież mogę się wypowiedzieć – jeżeli software house wytworzy coś ciekawego, co może sprzedać jeszcze wiele razy w przyszłości, to gdyby przekazała prawa majątkowe, to po prostu nie moglibyśmy odsprzedać dalej jakiegoś rozwiązania. Jeżeli zaś sprzedajemy to na licencji, która pozwala robić cokolwiek, klient chce, ale jednak zostawia prawa przy nas, to możemy to po prostu dalej odsprzedać, co po prostu może zmniejszyć późniejszy koszt odsprzedaży. Może taki produkt być bardziej dostępny.

Rozgadałem się na te tematy prawne, natomiast to jest naprawdę istotne i zdziwilibyście się, jak często takie tematy potrafią być niewyprostowane, niejasne, niedoprecyzowane. Na pewno warto jednak tutaj też wesprzeć się opinią specjalisty. I teraz prawo prawem, ale nawet, jeżeli te prawa masz, dostęp, licencję, to mimo wszystko są jeszcze kwestie techniczne, czyli trzeba sobie odpowiedzieć na pytanie, czy masz dostęp do całości aplikacji w infrastrukturze produkcyjnej i wszystkich innych komponentów, dzięki którym aplikacja działa. W naszej już ponad dwunastoletniej historii w Makimo, zdarzało się wielokrotnie, że firma – czasem nawet duża firma, i to może nawet częściej duża, bo brakowało osoby, która by się porządnie tym zajęła – korzystała z oprogramowania i nie mówimy tu o oprogramowaniu gotowym czy takim SAS-owym, które z definicji jest gdzieś tam w chmurze i nie mamy tak naprawdę nad nim kontroli, natomiast miała swoje niby oprogramowanie, ale ono było gdzieś na jakimś serwerze dostępne, a taka firma, taki klient nie miała dostępu do plików, do kont, żadnego wglądu. Oczywiście samo w sobie to nie musi być w żaden sposób niezgodne z ustaleniami czy nieuczciwe, często zdarza się, że klienci chcą oddelegować obowiązek opieki nad aplikacją, nad serwerem, czy to wykonawcy czy jeszcze jakiejś innej formie zajmującej się administracją. Natomiast mimo wszystko, uważam, że dobrą praktyką jest, aby klient miał - nawet jeżeli nie fizycznie dane dostępowe, to gdzieś tam w umowie zagwarantowane, że w razie czego, dostęp do aplikacji zostanie na przykład wydany w bieżącej wersji, że wszystkie dane zostaną udostępnione. Po prostu musi być jakaś forma wyegzekwowania aplikacji i - zwłaszcza potem - jej danych. Zdarzały się po prostu sytuacje, że kiedy ktoś chciał na przykład zmienić dostawcę, a umówmy się, że to często jest konsekwencją audytu, to niestety - dotychczasowy dostawca po prostu sprawiał problemy, powiedzmy.

Zagadnieniem pokrewnym, czyli już trzecią z tych reguł, zasad, jest dostęp, ale nie tyle do samej aplikacji, bo tutaj w tej drugiej zasadzie wspominałem o dostępie do środowiska produkcyjnego, do aplikacji, która działa, natomiast ważną kwestią jest też dostęp do kodu źródłowego, czyli do faktycznie tego, co zostało wytworzone przez dostawcę oprogramowania dedykowanego. Tutaj konieczne jest pewne rozróżnienie, to już jest kwestia mocno technologiczna, ale warto ją znać, bo może się wydawać dziwne, że się trochę powtarzam, przed chwilą mówiłem o dostępie do aplikacji, a teraz mówię o dostępie do aplikacji. Ale w kontekście kodu – różnica polega na tym, że w wielu technologiach, nie we wszystkich, ale w wielu popularnych technologiach, kiedy aplikacja jest tworzona w postaci kodu, można powiedzieć, że wtedy jest w takiej postaci czytelnej. Czytelnej, którą mogą wziąć inni programiści i dalej na przykład rozwijać, modyfikować. Natomiast aby uruchomić taką aplikację, konieczne jest przekształcenie postaci czytelnej dla człowieka, w postać czytelną dla maszyny. To się nazywa kompilacją, często też dochodzą pokrewne procesy, minifikowania, takiej optymalizacji pod przeglądarki internetowe czy też nawet celowej obfuskacji, czyli takiego zaciemnienia, powiedzmy, może w taki sposób. I teraz – z jednej strony taka aplikacja skompilowana, zminifikowana, ona działa, ona jest w pełni poprawna, natomiast uwierzcie mi – dalszy rozwój, modyfikacja takiego kodu jest praktycznie niemożliwa. Tutaj znowu, na etapie umowy warto zadbać o to, aby dostawca był zobowiązany do dostarczenia kodu w postaci właśnie takiej podstawowej, a nie zobfuskowanej, zminifikowanej czy właśnie tylko już skompilowanej, natomiast jeżeli takich zapisów nie masz, to myślę, że przy migracji dostawcy, tudzież po prostu w momencie, w którym audyt przeprowadza inna firma, warto poprosić ich o to, żeby zweryfikowali, jeżeli sami tego oczywiście nie zrobią, co jest jednak myślę, dość oczywiste – aby zweryfikowali, czy ten kod jest właśnie w takiej postaci, która umożliwi dalszy rozwój, bo bez tego, już nawet nie chodzi o robienie nowych funkcji w istniejącym oprogramowaniu, ale jakieś modernizacje bezpieczeństwa, dopasowanie pod kątem nowych systemów operacyjnych, nowych wersji tych zewnętrznych zależności – to wszystko w takim kodzie, który nie będzie w takiej postaci podstawowej, nieskompilowanej, niezminifikowanej, stanie się po prostu niemożliwy.

Dobrze, przechodzimy coraz bardziej w stronę technologii, kiedy już wiesz, że masz dostępy, masz uporządkowaną sytuację prawną, można zainteresować się stosem technologicznym. Stos technologiczny to zbiór technologii, czyli takich, jak chociażby nazwa i wersja języka programowania, nazwy, wersje, bibliotek, komponentów i zależności, z których korzysta dane wytworzone oprogramowanie dedykowane, chociażby wersja bazy danych, wersja systemu operacyjnego, na którym jest uruchomiona, czy też właśnie wersje takich komponentów, nie wiem, chociażby do łączenia się z bazą danych komponentu, który obsługuje nam aplikację webową, takie jak Jungle czy Railsy w technologii, w języku Ruby. To wszystko są, tak naprawdę, pozornie proste kwestie, bo to jest kwestia pewnej konfiguracji projektu, natomiast warto poddać ją analizie. Analiza powinna dotyczyć tego, jak – mówiąc wprost – stare są te komponenty. Jeżeli system był tworzony niedawno, to z reguły nie jest to problem. Jeżeli system był tworzony dawno, ale był na bieżąco aktualizowany, to również i te komponenty powinny być poddawane modernizacji. Natomiast jeżeli system był tworzony dawno i nie był aktualizowany, bo na przykład nie było na to budżetu, czy były ważniejsze sprawy, to niestety robi się tu pewien problem, bo możesz mieć do czynienia z technologią, nawet jeżeli aplikacja sama w sobie działa dobrze, ale technologia może utrudniać spełnianie najnowszych standardów bezpieczeństwa czy dopasowania do bieżących wersji ogólnych, na przykład systemów operacyjnych czy innych zależności, fundamentów, na których funkcjonuje cała aplikacja, właśnie z całym stosem technologicznym. I wreszcie dochodzimy do zasadniczego etapu, audytu kodu, czyli audytu samej aplikacji. Tak naprawdę, kiedy zacząłem się rozpisywać na te inne tematy, szykować sobie notatki, ja mam takie z reguły bulletpointy, czyli wykaz – może tak po polsku - co chcę powiedzieć, to wyszło tego tak dużo, że jednak tutaj wspomnę o tym audycie i prawdopodobnie znowu będzie to forma wstępu do jeszcze kolejnego odcinka, gdzie już wyłącznie opowiem o samym audycie oprogramowania już pod kątem stricte technicznym. Natomiast taki audyt przede wszystkim polega na analizie kodu oprogramowania, czyli tego, co faktycznie wytworzył poprzedni dostawca. Konieczna jest ocena przede wszystkim ocena czytelności i zarządzalności projektu. Tutaj zakładamy, że aplikacja jako taka działa. Jeżeli wiesz, że coś jest w niej nie tak, to jest jakby jeszcze osobny temat. Pytanie brzmi, czy kolejni specjaliści, z jakiejś innej firmy, będą w stanie kontynuować rozwój albo chociaż utrzymać aplikację przy życiu. Nie jest to temat łatwy, bo to też nie jest tak, że każdy programista, programistka podejdzie do oprogramowania i stwierdzi: nie, nie, to jest nie tak – i będzie to opinia wszystkich. Może się zdarzyć, że na przykład osoby o mniejszym doświadczeniu czy trochę innej specjalizacji technologicznej, nie będą w stanie sobie poradzić z oprogramowaniem, a inna firma, inni specjaliści – już tak. Natomiast to jednak są rzadsze sytuacje, częściej aplikacja może być na przykład napisana w tak tragiczny sposób, że mówi się o tak zwanej „spaghettifikacji kodu”, czyli sytuacji, w której kod jest niesamowicie pogmatwany, poszczególne fragmenty aplikacji odwołują się do siebie nawzajem, trochę tak, jak w makaronie spaghetti poszczególne nitki są poplątane, splątane z innymi. Warto więc też zwrócić uwagę na obecność tak zwanych jednostkowych, ale też nie tylko jednostkowych, testów automatycznych, które polegają na tym, że jesteśmy w stanie w, no, może nie kilka czy kilkanaście sekund, ale na przykład w kilka minut, uruchomić zestaw testów dla całego oprogramowania i zweryfikować, czy wszystkie pojedyncze funkcje, które zostały oczywiście ujęte w testach, działają prawidłowo. To pozwala na uniknięcie tak zwanych regresji, czyli błędów, wynikających z tego, że gdy zmienimy jakąś pozornie drobną funkcję, na przykład, załóżmy, mechanizm rejestracji w systemie, to nagle przestają działać inne, bo na przykład są ze sobą w nieprawidłowy sposób powiązane. W momencie, w którym mamy takie teksty, ryzyko, że ktoś doda nową funkcję, która przez przypadek zepsuje inną, staje się dużo mniejsze, bo wtedy testy na przykład przestają, jak to się mówi, przechodzić – przestają być prawidłowe, przez co wtedy jak ktoś na przykład doda taką problematyczną zmianę, to zauważy – o, testy nie przechodzą, to ja muszę jednak coś tutaj poprawić, bo naruszyłem jakiś inny mechanizm. Tak że zdecydowanie to, co mogę powiedzieć to to, że brak testów oznacza, że ryzyko utrzymania projektu staje się po prostu dużo większe. I są oczywiście inne aspekty, gdzie nie tylko samą czytelność kodu, zarządzalność kodu warto oceniać zdecydowanie tutaj audyt bezpieczeństwa, na przykład oprogramowanie, można by jeszcze opisać, audyt wydajności, użyteczności – oprogramowanie można badać pod innymi, bardzo różnymi względami, i myślę, że to już będzie temat na odrębny odcinek, ale taka najbardziej klasyczna analiza, czyli właśnie analiza kodu, jest czymś, co na pewno jest istotne, bo jeżeli kod jest tragicznie napisany, to usprawnienie tych pozostałych aspektów, będzie po prostu bardzo trudne.

I wreszcie, last, but not least, jak to się mówi, dobry projekt – to jest ta szósta zasada audytu – dobry projekt powinien być też dobrze udokumentowany, nie tylko w samym kodzie, ale też z punktu widzenia innych u użytkowników, interesariuszy projektu. O co chodzi? Chodzi o to, aby w sytuacji, w której po paru miesiącach, po roku, po półtora roku, gdy programiści być może skończą już pracę nad projektem, będzie on używany, nowe osoby będą mogły dołączyć, zacząć korzystać z projektu i nie będzie trzeba gdzieś odwoływać się do doświadczeń programistów z dawnej przeszłości. Występują różne rodzaje dokumentacji, ja bym tutaj chciał wspomnieć o trzech – dokumentacji instalatora, czyli osoby, która jest w stanie wziąć komplet plików od dostawcy i po prostu doprowadzić do uruchomienia systemu. Dokumentacja administratora, czyli użytkownik, który ma jakieś nadrzędne uprawnienia, zarządza całym systemem. I dokumentacja użytkownika, czyli to już tacy zwykli, można powiedzieć, użytkownicy systemu. I tutaj zwłaszcza ta instalacyjna dokumentacja jest ważna, bo często jest tak, że na przykład okazuje się w którymś momencie, że po paru latach od wdrożenia trzeba zrobić migrację na nowy serwer, do jakiejś nowej chmury czy po prostu do nowego środowiska i nagle nikt nie pamięta, jak to właściwie było. Z dobrą dokumentacją zdecydowana większość problemów da się rozwiązać. My mieliśmy kiedyś taką sytuację, że był projekt, który zrealizowaliśmy, klient sobie go sam wspierał, myśmy już nawet myśleli, że może nawet przestał być używany, bo kompletnie komunikacja zamarła na dwa lata, ale odezwał się właśnie administrator serwerów, który stwierdził, że serwer został zmigrowany i że w sumie to chcieliby zainstalować to oprogramowanie, jedno to, że zgubili dokumentację, więc to też, jak widać, może być problem. Na szczęście ja tam gdzieś w archiwum miałem, przesłałem plik i nawet się nie odezwali, w sumie nawet nie podziękowali jakoś za bardzo, ale najważniejsze, co też świadczy o roli dobrej dokumentacji jest to, że nie były potrzebne żadne wyjaśnienia, wystarczył jeden plik w Wordzie.

I na tym kończymy ten odcinek, jeżeli wszystkie te punkty, które opisałem, sprawdzisz, że wszystko będzie w porządku, to gratuluję, 6 na 6, taki software na szóstkę, natomiast na pewno warto co jakiś czas analizować, czy w ogóle raz przeanalizować pod kątem prawnym, ale pod kątem technicznym nawet częściej te wybrane zagadnienia. Ja też będę nagrywał jeszcze jeden odcinek, stricte już o aspektach technicznych audytu oprogramowania, natomiast jeżeli w międzyczasie będziesz chciał, chciała dowiedzieć się czegoś więcej, czy na przykład poradzić się w jakiejś konkretnej sprawie, bo przecież jest takie oprogramowanie, inne oprogramowanie, mamy ogrom technologii, modeli działania i trudno jest ująć wszystko w formie takich reguł przedstawionych w odcinku podcastu jednym, nie mówiąc o jakimś może szerszym cyklu, ale nawet gdyby był szerszy cykl, to i tak zawsze się o czymś nie powie, bo jest to po prostu temat – rzeka. Natomiast ja chętnie też doradzę, podpowiem może coś, w którym kierunku iść, z chęcią doradzę, co można zrobić w różnych sytuacjach. Tak że jeżeli ktoś z was ma taką sytuację, ma taki problem, zachęcam do kontaktu, czy to przez LinkedIn, czy to przez Messengera, czy na maila: krzysztof@makimo.pl, zapraszam.

Na dziś to już wszystko, dziękuję bardzo za uwagę, kłaniam się nisko i do usłyszenia.

KONIEC