System działa, ale firma planuje jego dużą rozbudowę. Dotychczasowy wykonawca ma zostać zastąpiony innym software house’em. Rozwój systemu zajmuje coraz więcej czasu. Aktualizacja technologii jest odkładana od kilku lat. Nikt nie potrafi jednoznacznie powiedzieć, które elementy aplikacji można bezpiecznie zmieniać.
W takich sytuacjach problemem często nie jest brak kolejnego pomysłu na rozwój systemu. Problemem jest brak wiedzy o jego rzeczywistym stanie technicznym.
Właśnie temu służy audyt techniczny systemu informatycznego.
Nie powinien być jedynie automatycznym skanem kodu ani listą kilkuset uwag dotyczących standardów programistycznych. Jego zadaniem jest ustalenie, czy istniejący system można bezpiecznie utrzymywać i dalej rozwijać, gdzie znajdują się największe ryzyka oraz które problemy rzeczywiście wymagają działania.
W zależności od projektu audyt może obejmować kod źródłowy, architekturę, technologie, bazę danych, integracje, bezpieczeństwo, testy, infrastrukturę, proces wdrażania zmian, monitoring i dokumentację.
Najważniejszy jest jednak rezultat.
Po audycie firma powinna wiedzieć:
W tym artykule przeczytasz:
Audyt techniczny systemu informatycznego to uporządkowana analiza istniejącego oprogramowania, której celem jest ocena jego stanu technicznego, ryzyka oraz możliwości dalszego utrzymania i rozwoju.
W zależności od projektu przedmiotem analizy może być:
Audyt powinien patrzeć na system szerzej niż tylko poprzez kod. Dobrze napisany kod może bowiem działać na źle zarządzanej infrastrukturze. Nowoczesna infrastruktura może obsługiwać aplikację opartą na trudnej do rozwijania architekturze. System może mieć wysokie pokrycie testami, ale korzystać z krytycznej, niewspieranej zależności. Może też być poprawny technologicznie, a mimo to posiadać proces wdrażania zmian, który potrafi przeprowadzić tylko jeden developer.
Dlatego audyt techniczny systemu powinien obejmować cały kontekst potrzebny do jego bezpiecznego rozwoju, a nie wyłącznie wybrane pliki źródłowe.
Nie. Audyt kodu źródłowego jest jednym z możliwych elementów szerszego audytu technicznego. Podczas analizy kodu można sprawdzać między innymi:
To ważna część analizy. Nie odpowiada jednak na wszystkie pytania.
Kod sam w sobie nie pokaże pełnego obrazu dotyczącego:
Dlatego audyt kodu źródłowego i audyt techniczny systemu informatycznego nie powinny być traktowane jako pojęcia zamienne. Pierwszy analizuje przede wszystkim kod.
Drugi odpowiada na szersze pytanie: w jakim stanie znajduje się rozwiązanie, które firma ma dalej utrzymywać i rozwijać?
Słowo „audyt” obejmuje bardzo różne usługi. Warto więc rozróżnić ich cele.
Koncentruje się na użytkowniku.
Analizuje między innymi:
Ocenia przede wszystkim czynniki wpływające na widoczność witryny w wyszukiwarkach. Może obejmować strukturę strony, indeksację, metadane, linkowanie, możliwość prawidłowego odczytywania strony przez roboty wyszukiwarek, wydajność czy problemy techniczne związane z SEO.
Może łączyć UX, wydajność, SEO, analitykę i analizę procesu zakupowego.
Jego głównym pytaniem jest zwykle: co ogranicza skuteczność sklepu i jego sprzedaż? Jeżeli to właśnie sprzedaż, UX, wydajność i proces zakupowy są przedmiotem analizy, osobno opisaliśmy, na czym polega audyt sklepu internetowego.
Koncentruje się na podatnościach, powierzchni ataku i zabezpieczeniach systemu.
Pyta natomiast: czy techniczne fundamenty istniejącego rozwiązania pozwalają bezpiecznie je utrzymywać, zmieniać i rozwijać?
Zakresy mogą się częściowo przecinać. Nie należy jednak zastępować jednego audytu drugim.
To kolejne ważne rozróżnienie. Analiza przedwdrożeniowa wykonywana jest przede wszystkim po to, aby dobrze przygotować plan realizacji nowego rozwiązania lub istotnego nowego zakresu.
Odpowiada na pytania takie jak:
Audyt techniczny zaczyna natomiast od czegoś, co już istnieje.
Nie pytamy: Co powinniśmy zbudować?
Najpierw pytamy: Co właściwie mamy?
I dopiero później: Czy możemy na tym bezpiecznie budować dalej?
To sprawia, że audyt techniczny jest szczególnie istotny przed rozwojem starszego systemu, zmianą wykonawcy, większą modernizacją albo inwestycją w kolejną fazę projektu.
Nie każdy projekt wymaga rozbudowanego audytu. Są jednak sytuacje, w których poznanie stanu technicznego systemu przed podjęciem kolejnej decyzji może znacząco ograniczyć ryzyko.
Nowy zespół nie zna jeszcze historii systemu, jego niejawnych zależności ani problemów pojawiających się podczas codziennego utrzymania. Audyt pozwala ograniczyć tę niewiedzę przed przejęciem odpowiedzialności za dalszy rozwój aplikacji.
Sam proces zmiany wykonawcy opisujemy szerzej w poradniku Przejęcie projektu IT po innym wykonawcy – jak bezpiecznie zmienić software house.
Jeżeli firma planuje istotną inwestycję w kolejną wersję produktu, warto najpierw sprawdzić, czy obecna architektura, technologie i kluczowe moduły są odpowiednią podstawą dla nowych funkcjonalności.
Jeżeli podobne zmiany wymagają coraz więcej pracy, przyczyną może być rosnąca złożoność, niewłaściwa architektura albo dług technologiczny.
Audyt pomaga ustalić, gdzie rzeczywiście znajduje się źródło rosnącego kosztu developmentu.
Duża aktualizacja frameworka, środowiska uruchomieniowego, bazy danych lub infrastruktury może wpływać na wiele elementów rozwiązania. Audyt pozwala zidentyfikować zależności i ryzyka przed rozpoczęciem zmian.
Jeżeli aplikacja wpływa bezpośrednio na sprzedaż, produkcję, obsługę klientów lub inne istotne procesy firmy, znajomość jej technicznych słabości ma szczególne znaczenie.
Jeżeli rozważane jest zastąpienie istniejącej aplikacji nowym rozwiązaniem, najpierw warto ustalić, które problemy rzeczywiście wynikają z jej fundamentów, a które można rozwiązać bez pełnego rewrite’u.
System może nadal działać poprawnie, ale przez lata mogły narosnąć zależności, nieaktualne komponenty, obejścia i problemy dokumentacyjne. Audyt pozwala ocenić ich rzeczywisty wpływ przed kolejnym etapem rozwoju.
Dobra analiza nie powinna kończyć się stwierdzeniem: Automatyczne narzędzia wykryły w kodzie 247 problemów i ostrzeżeń. To może być informacja pomocnicza.
Dla osoby zarządzającej systemem ważniejsze są pytania:
Audyt techniczny powinien wspierać decyzję, a nie produkować problemy do raportu.
Zakres zawsze powinien być dopasowany do projektu. W rozbudowanych systemach warto jednak przeanalizować co najmniej kilka podstawowych warstw.
Architektura decyduje o tym, jak poszczególne elementy aplikacji współpracują ze sobą.
Podczas audytu warto ustalić między innymi:
Nie istnieje jedna architektura właściwa dla wszystkich systemów. Monolit nie jest automatycznie problemem.
Mikroserwisy nie są automatycznie oznaką dojrzałości.
Najważniejsze pytanie brzmi: czy obecna architektura odpowiada skali, potrzebom i przewidywanemu kierunkowi rozwoju systemu?
Analiza kodu nie powinna sprowadzać się do stylistyki. Znacznie ważniejsze jest to, czy kolejny software developer może sprawnie zrozumieć system i bezpiecznie wprowadzać w nim zmiany.
Warto sprawdzić między innymi:
Narzędzia statycznej analizy mogą pomóc znaleźć część problemów, ale nie zastępują analizy uwzględniającej logikę i kontekst aplikacji. Automatyczne skanery dobrze wykrywają określone klasy błędów i nieprawidłowości, ale mogą nie wychwycić problemów wynikających ze sposobu przepływu danych, zależności pomiędzy modułami czy specyficznej logiki biznesowej.
System nie istnieje w próżni.
Korzysta z:
Podczas audytu trzeba sprawdzić:
Nie chodzi o wymianę każdej biblioteki tylko dlatego, że istnieje nowsza wersja. Problem pojawia się wtedy, gdy zależność wpływa na bezpieczeństwo, możliwość dalszych aktualizacji lub zdolność do rozwijania systemu. OWASP wskazuje podatne i nieaktualne komponenty jako istotny obszar ryzyka aplikacji, dlatego zarządzanie zależnościami powinno być elementem technicznej oceny istniejącego rozwiązania.
Audyt jest bardzo dobrym momentem do zidentyfikowania długu technologicznego. Nie chodzi jednak o stworzenie możliwie długiej listy niedoskonałości.
Trzeba ustalić przede wszystkim:
Fragment kodu, który nie jest idealny, ale działa stabilnie i od lat nie wymaga zmian, może mieć znacznie niższy priorytet niż mniej spektakularny problem w module rozwijanym każdego tygodnia. Dlatego audyt długu technologicznego powinien być powiązany z rzeczywistym sposobem rozwoju systemu.
W wielu systemach to właśnie dane są najtrudniejszym elementem późniejszej modernizacji.
Audyt może obejmować:
Warto również ustalić, czy model danych nadal odpowiada procesom biznesowym. System rozwijany przez osiem lat może przechowywać informacje w sposób wynikający z decyzji podjętych dla zupełnie innej skali działalności.
Integracje należą do obszarów, które przy audycie łatwo pominąć, jeżeli analiza skupia się wyłącznie na repozytorium.
Tymczasem system może zależeć od:
Warto ustalić:
Działająca integracja niekoniecznie jest integracją odporną na awarie. Audyt powinien sprawdzić również scenariusze, w których coś przestaje działać.
Audyt techniczny nie musi zastępować pełnego audytu bezpieczeństwa czy testów penetracyjnych.
Powinien jednak zidentyfikować oczywiste ryzyka mogące wpływać na dalsze utrzymanie projektu.
W zależności od zakresu może to obejmować między innymi:
Bezpieczeństwa nie warto analizować wyłącznie poprzez skaner. OWASP podkreśla znaczenie manualnego przeglądu kodu oraz analizy logiki aplikacji, a NIST SSDF traktuje przegląd, analizę i testowanie kodu jako element bezpiecznego procesu wytwarzania oprogramowania.
Jeżeli istnieje podejrzenie konkretnych podatności lub system przetwarza szczególnie wrażliwe dane, potrzebny może być dodatkowy audyt bezpieczeństwa lub test penetracyjny (pentest).
Testy mają ogromne znaczenie przy systemie, który ma być dalej rozwijany.
Podczas audytu warto sprawdzić:
Sama liczba testów nie jest najważniejsza.
Dużo ważniejsze jest pytanie: czy przed zmianą krytycznego modułu zespół ma mechanizm pozwalający zweryfikować, że nie zepsuł innej części systemu?
System może być dobrze napisany, a mimo to jego utrzymanie będzie ryzykowne z powodu infrastruktury.
Audyt powinien odpowiedzieć między innymi na pytania:
Szczególnie ważne jest ustalenie, czy konfiguracja środowisk jest powtarzalna i czy nowy zespół byłby w stanie uruchomić aplikację bez wiedzy dostępnej wyłącznie u jednej osoby.
W bardziej rozbudowanych systemach proces budowania, testowania i wdrażania kolejnych wersji może być częściowo lub całkowicie zautomatyzowany, często w ramach mechanizmów określanych jako CI/CD. Sposób wdrażania kolejnych zmian jest często jednym z najbardziej niedocenianych elementów audytu.
Warto ustalić:
Jeżeli wdrożenie zmian polega na ręcznym kopiowaniu wybranych plików przez osobę, która „wie, które trzeba przesłać”, problemem systemu nie jest tylko kod. Problemem jest proces.
System może działać nieprawidłowo przez kilka godzin, zanim ktokolwiek to zauważy.
Dlatego audyt powinien zweryfikować:
W rozbudowanych systemach samo pytanie „czy serwer odpowiada?” może być niewystarczające. Aplikacja może działać, podczas gdy synchronizacja zamówień z ERP nie działa od kilku godzin.
Kopia zapasowa istnieje? To jeszcze nie jest najważniejsze pytanie.
Ważniejsze są:
Kopia zapasowa, której nigdy nie próbowano wykorzystać do odtworzenia systemu, daje znacznie mniejszą pewność niż regularnie weryfikowany proces odtwarzania.
Brak dokumentacji nie oznacza automatycznie złego projektu.
Znacząco zwiększa jednak zależność od osób, które znają system.
Audyt powinien sprawdzić:
Szczególnie niebezpieczna jest sytuacja, w której istnieją procesy, które: „zna tylko Marek”.
Wtedy firma posiada nie tylko ryzyko technologiczne, ale również organizacyjne.
Audyt może ujawnić problem, który nie znajduje się ani w kodzie, ani w architekturze.
Firma może nie kontrolować:
To szczególnie ważne przed zmianą wykonawcy. Właściciel projektu powinien wiedzieć, jakie zasoby istnieją, kto jest ich właścicielem i kto ma do nich dostęp.
Wydajność należy analizować w kontekście realnych wymagań.
System obsługujący 200 użytkowników dziennie nie musi być projektowany tak samo jak platforma generująca tysiące operacji na minutę.
Audyt może obejmować:
Najważniejsze pytanie nie brzmi: Czy system jest nieskończenie skalowalny?
Tylko: Czy jest wystarczająco skalowalny dla przewidywanego rozwoju biznesu?
Zanim rozpoczniesz kolejny etap rozwoju systemu, warto sprawdzić, czy obecna architektura, kod, integracje i infrastruktura są dobrą podstawą dalszych inwestycji.
To bardzo ważne. Audytor zawsze może znaleźć coś, co dałoby się zaprojektować „lepiej”.
Można:
Ale fakt, że coś można zmienić, nie oznacza jeszcze, że warto.
Audyt powinien brać pod uwagę:
Celem nie jest stworzenie technologicznie idealnego systemu. Celem jest system, który można odpowiedzialnie utrzymywać i rozwijać.
W branży określa się to często jako overengineering – projektowanie rozwiązania znacznie bardziej skomplikowanego, niż wymaga tego rzeczywisty problem.
Narzędzia są bardzo przydatne. Mogą analizować między innymi:
Nie rozumieją jednak całego kontekstu biznesowego. Program może wskazać skomplikowaną metodę. Nie powie natomiast, czy odpowiada ona za proces używany raz w roku, czy za mechanizm wyceny realizujący 40% przychodów firmy. Może wskazać przestarzałą bibliotekę. Nie zawsze odpowie, jakie konsekwencje dla działalności firmy będzie miała jej wymiana.
Dlatego automatyczna analiza powinna być źródłem danych dla audytora, a nie samym audytem. OWASP wskazuje wprost na rolę ręcznej analizy kodu w wykrywaniu problemów związanych z logiką aplikacji i przepływem danych, których narzędzia automatyczne mogą nie wykryć.
AI może bardzo dobrze wspierać analizę.
Może pomóc w:
Nie rozwiązuje jednak podstawowego problemu audytu.
Ktoś nadal musi zdecydować:
Audyt techniczny wymaga więc nie tylko analizy, ale również oceny. To dwie różne rzeczy.
Tutaj znajduje się najważniejsza różnica pomiędzy użytecznym audytem a raportem, który później trafia do szuflady.
Każdy istotny problem warto ocenić w trzech wymiarach.
Co może się wydarzyć?
Na przykład:
Co oznacza to dla firmy?
Przykładowo:
Czy problem będzie droższy za rok? Niektóre problemy praktycznie się nie zmieniają. Inne narastają.
Przykładowo aktualizacja biblioteki może być dzisiaj stosunkowo prosta, ale za kilka kolejnych wersji wymagać wieloetapowej migracji.
Dopiero połączenie tych trzech wymiarów pozwala sensownie ustalać priorytety.
Zamiast kończyć raport klasyfikacją:
bardziej praktyczne może być podzielenie rekomendacji na cztery grupy.
Problemy wpływające na:
Problemy, które nie wymagają działania dzisiaj, ale wyraźnie podnoszą koszt kolejnych zmian.
Elementy, które mogą stać się problemem wraz ze zmianą skali lub rozwojem systemu.
Problemy techniczne, których koszt rozwiązania jest obecnie nieproporcjonalny do korzyści.
Ta ostatnia grupa jest równie ważna jak pierwsza. Dobry audyt powinien potrafić powiedzieć również: tego teraz nie warto ruszać.
To jeden z najważniejszych przypadków wykorzystania audytu technicznego. Nowy zespół przejmuje bowiem nie tylko kod, ale również istniejące zależności, ograniczenia i ryzyka techniczne projektu.
System może posiadać:
Dlatego przed przejęciem trzeba zmniejszyć poziom niewiedzy. Audyt nie musi oznaczać kilkutygodniowej analizy wszystkiego.
Zakres powinien odpowiadać pytaniu: co musimy wiedzieć, żeby odpowiedzialnie przejąć ten konkretny system?
Jeżeli po audycie potrzebny jest zespół odpowiedzialny za przejęcie, modernizację i dalszy rozwój istniejącego rozwiązania, zobacz Firma programistyczna.
Przy przejmowaniu projektu priorytetem powinny być:
Czy nowy zespół potrafi uruchomić system na podstawie otrzymanych materiałów?
Czy repozytorium rzeczywiście zawiera wersję działającą obecnie na serwerze?
Czy firma kontroluje wszystkie krytyczne usługi?
Czy wiadomo, jak bezpiecznie wdrożyć pierwszą zmianę?
Czy w przypadku problemu można odtworzyć system?
Czy wiadomo, od jakich zewnętrznych systemów zależy aplikacja?
Czy istnieje coś, co wymaga działania przed rozpoczęciem regularnego rozwoju systemu?
Dopiero później można przejść do szczegółowego porządkowania kodu.
Drugi ważny scenariusz występuje wtedy, gdy obecny wykonawca pozostaje, ale firma planuje istotną inwestycję.
Przykładowo:
W takiej sytuacji audyt powinien odpowiedzieć: czy nowe funkcjonalności powinny powstawać na obecnym fundamencie?
Czasem odpowiedź będzie brzmiała: tak, system jest w dobrym stanie – rozwijamy dalej.
Czasem: tak, ale najpierw warto uporządkować dwa konkretne moduły.
A czasem: obecna architektura będzie bardzo kosztownym fundamentem dla planowanego zakresu i warto ją wcześniej zmodernizować.
Każda z tych odpowiedzi jest wartościowa.
Refaktoryzacji nie powinno się rozpoczynać od przypadkowego fragmentu kodu.
Największą wartość daje zwykle uporządkowanie tych obszarów, które:
Audyt pomaga ustalić, gdzie refaktoryzacja kodu może przynieść największą wartość i rzeczywiście ograniczyć koszt dalszego rozwoju systemu. Nie chodzi o to, aby poprawić jak najwięcej kodu. Chodzi o to, aby usunąć problemy, które generują największy koszt dalszego rozwoju.
W przypadku starszych systemów audyt ma jeszcze jedno zadanie: oddzielić wiek technologii od rzeczywistego problemu.
Stary framework nie oznacza automatycznie, że aplikację trzeba przepisać. Podobnie nowoczesny framework nie gwarantuje dobrej architektury.
Trzeba sprawdzić:
Dopiero potem można wybierać pomiędzy:
Tak. I taki rezultat może być bardzo wartościowy. Firma planuje dużą inwestycję i obawia się, że system jest „za stary”.
Audyt może wykazać, że:
Wtedy rekomendacją może być: rozwijamy system dalej, a niewielkie problemy porządkujemy w ramach bieżącego utrzymania i wsparcia technicznego.
Audyt nie powinien być narzędziem służącym do uzasadnienia sprzedaży nowego systemu. Powinien pomóc podjąć właściwą decyzję.
Proces będzie zależał od zakresu, ale najczęściej warto przejść kilka etapów.
Najpierw ustalamy: dlaczego wykonujemy audyt?
Inaczej analizuje się system przed:
Bez jasno określonego celu łatwo analizować rzeczy, które nie mają znaczenia dla decyzji.
Potrzebne mogą być:
Nie zawsze wszystko będzie dostępne. Braki same w sobie są informacją o projekcie.
Zanim zacznie się szczegółową ocenę kodu, trzeba zrozumieć:
Zakres może obejmować kod, architekturę, bazę danych, zależności, infrastrukturę, testy i pozostałe elementy opisane wcześniej.
Kod nie odpowie na każde pytanie.
Rozmowa z developerami może wyjaśnić:
Wykryte problemy trzeba połączyć z ich wpływem na system oraz biznes.
Raport powinien kończyć się odpowiedzią: co robimy dalej?
Nie ma jednego obowiązkowego szablonu. Przy większym systemie dobrym rozwiązaniem jest jednak podział na kilka poziomów informacji.
Krótka odpowiedź dla osób decyzyjnych:
Najważniejsze informacje o:
Każdy istotny problem powinien mieć:
Co:
Jeżeli ma to sens, rekomendacje warto pogrupować w etapy.
Przede wszystkim nie powinien być listą problemów bez kontekstu.
Informacja: „klasa ma 900 linii”
sama w sobie niewiele mówi osobie odpowiedzialnej za budżet systemu.
Znacznie bardziej przydatne jest: „moduł odpowiada za kluczowy proces zamówień, jest zmieniany przy większości nowych funkcjonalności i posiada wiele niejawnych zależności, dlatego każda modyfikacja wymaga szerokich testów regresyjnych”.
Pierwsze zdanie opisuje kod. Drugie opisuje problem.
Nie. W dużych rozwiązaniach pełny audyt wszystkiego może być nieproporcjonalnie kosztowny.
Można wykonać audyt ograniczony do:
Można również rozpocząć od szybszej analizy wysokiego poziomu i dopiero na jej podstawie rozszerzyć zakres. Najważniejsze jest dopasowanie pracy do decyzji, którą trzeba podjąć.
Można przeanalizować wybrane obszary:
Nie będzie to jednak pełny audyt techniczny systemu. Bez kodu trudno odpowiedzialnie ocenić między innymi jego utrzymywalność, część problemów architektonicznych czy sposób implementacji logiki biznesowej.
Może. Ma to praktyczną zaletę: zespół wykonujący analizę zdobywa wiedzę potrzebną później podczas dalszego rozwoju systemu.
Trzeba jednak zachować jedną ważną zasadę. Audyt nie może automatycznie prowadzić do wniosku: „wszystko trzeba przepisać i najlepiej, żebyśmy zrobili to my”.
Rekomendacje powinny wynikać z rzeczywistego stanu projektu. Dobry software house powinien być w stanie wskazać również elementy, których nie warto zmieniać.
W przypadku WordPressa i WooCommerce zakres będzie częściowo inny niż przy dedykowanej aplikacji.
Warto sprawdzić między innymi:
W sklepie WooCommerce dochodzą procesy krytyczne biznesowo:
To jednak nadal audyt techniczny systemu, a nie audyt konwersji sklepu. Nie analizujemy tutaj, czy CTA ma odpowiedni kolor albo karta produktu optymalnie prowadzi użytkownika do zakupu.
Pytamy: czy techniczne fundamenty sklepu pozwalają bezpiecznie go utrzymywać i rozwijać?
W przypadku systemów dedykowanych szczególnego znaczenia nabiera logika biznesowa.
Takie rozwiązanie mogło powstawać przez wiele lat i zawierać reguły dotyczące:
Nie wszystkie nietypowe fragmenty kodu są błędami. Niektóre odwzorowują bardzo nietypowy proces przedsiębiorstwa. Dlatego audyt dedykowanego systemu wymaga zarówno wiedzy technicznej, jak i zrozumienia sposobu działania biznesu.
Systemy B2B bardzo często są silnie połączone z pozostałą infrastrukturą przedsiębiorstwa.
Mogą korzystać z:
Audyt powinien wtedy analizować nie tylko samą aplikację, ale cały przepływ procesu pomiędzy systemami. Problem widoczny w B2B może mieć źródło po stronie ERP. Albo odwrotnie.
W przypadku istniejącego projektu pierwszym celem jest zrozumienie jego stanu oraz problemu, który firma chce rozwiązać. Zakres analizy powinien wynikać z celu.
Inaczej podchodzimy do systemu, który ma zostać przejęty po innym wykonawcy, inaczej do aplikacji przed dużą rozbudową, a jeszcze inaczej do projektu wymagającego modernizacji technologicznej.
Jako software house patrzymy nie tylko na kod. W zależności od projektu analizie mogą podlegać:
Efektem powinna być przede wszystkim podstawa do podjęcia decyzji. Nie lista rzeczy, które technicznie można poprawić.
Największą wartością audytu nie jest liczba znalezionych problemów. Jest nią zmniejszenie niepewności.
Przed analizą firma może nie wiedzieć:
Po audycie odpowiedzi powinny być znacznie bardziej konkretne. Nie każdy problem trzeba usuwać. Nie każdą starą technologię trzeba wymieniać. Nie każdy system z długiem technologicznym trzeba przepisywać.
Ale nie powinno się również inwestować dużego budżetu w kolejną fazę systemu bez wiedzy, czy jego fundamenty są na nią przygotowane. Dobry audyt techniczny pozwala więc odpowiedzieć na jedno najważniejsze pytanie: co powinniśmy zrobić z tym systemem dalej?
Zanim zdecydujesz się na kolejną dużą inwestycję, zmianę wykonawcy albo przebudowę aplikacji, warto najpierw poznać jej rzeczywisty stan techniczny. Możemy przeanalizować istniejący system i wskazać obszary, które wymagają działania, te które warto zaplanować na później oraz elementy, których obecnie nie ma potrzeby zmieniać.
To analiza stanu istniejącej aplikacji obejmująca zależnie od potrzeb architekturę, kod, technologie, dane, integracje, testy, infrastrukturę, monitoring i proces wdrażania zmian.
Audyt kodu koncentruje się przede wszystkim na implementacji. Audyt techniczny jest szerszy i może obejmować również architekturę, bazę danych, integracje, infrastrukturę, deployment, testy i dokumentację.
Przede wszystkim przed przejęciem projektu, dużą rozbudową, modernizacją technologii lub decyzją o napisaniu systemu od nowa. Jest również przydatny, gdy rozwój aplikacji staje się coraz wolniejszy lub mniej przewidywalny.
Nie. Bezpieczeństwo może być jednym z elementów audytu technicznego, ale pełny audyt bezpieczeństwa i testy penetracyjne mają bardziej specjalistyczny zakres.
Tak. Pozwala poznać architekturę, stan kodu, integracje, infrastrukturę i najważniejsze ryzyka przed przejęciem odpowiedzialności za istniejący projekt.
Tak. Audyt może zidentyfikować dług technologiczny i ocenić jego wpływ na dalszy development, stabilność oraz koszt utrzymania systemu.
Nie. Wynikiem audytu może być również rekomendacja dalszego rozwoju obecnego systemu bez większej przebudowy albo uporządkowania tylko wybranych obszarów.
Tak. Brak dokumentacji zwiększa zakres potrzebnej analizy, ale część wiedzy można odtworzyć na podstawie kodu, konfiguracji, infrastruktury, bazy danych i działania systemu.
Zależy od wielkości systemu, zakresu analizy, liczby integracji, dostępnej dokumentacji oraz celu audytu. Analiza jednego modułu i audyt wieloletniej platformy to dwa zupełnie różne zakresy.
Przede wszystkim opis najważniejszych ryzyk, ich wpływu i priorytetów oraz rekomendacja kolejnych działań. Przy większych projektach wynikiem może być również roadmapa techniczna dalszych prac.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Jak bezpiecznie przejąć projekt IT po innym wykonawcy? Sprawdź kod, dostępy, infrastrukturę, dokumentację i proces zmiany software house.
Czym jest refaktoryzacja kodu i kiedy ma sens? Sprawdź, czym różni się od rewrite’u i modernizacji oraz jak zaplanować bezpieczne zmiany w systemie.
Jak bezpiecznie przejąć projekt IT po innym wykonawcy? Sprawdź kod, dostępy, infrastrukturę, dokumentację i proces zmiany software house.
Time & Material czy Fixed Price? Porównaj sposób rozliczenia, ryzyko, kontrolę budżetu i zmiany zakresu. Sprawdź, który model pasuje do projektu IT.
Share:
