Cykl życia oprogramowania – Software Development Life Cycle

Cykl życia oprogramowania (and. Software Development Life Cyckle – SDLC) jest usystematyzowanym podejściem do tworzenia, rozwoju oraz wycofywania danego programowania. Dzięki procesowemu podejściu wspartego przez narzędzia IT zarządzamy zarówno tym oprogramowaniem, podnosimy jakość, zmniejszamy dług technologiczny oraz zwiększamy dojrzałość organizacji wytwarzania oprogramowania.

SDLC może składać się z kilku procesów:

  1. Analiza wstępna – faza inicjalna dla każdego projektu biznesowego czy informatycznego. Określamy potrzeby, wymagania, potencjalne koszty, możliwości, zasoby potrzebne do realizacji czy ryzyka dla danego projektu. Jego potencjalne korzyści biznesowe, ramy czasowe czy opłacalność (ROI).
  2. Analiza szczegółowa, spis wymagań – szczegółowa analiza wymagań odnośnie systemów, ich integracji, kosztów, harmonogramu prac, zwrotów z inwestycji, ryzyk projektowych, itd. Analiza aspektów technologicznych, UX (User Experience), prawnych, bezpieczeństwa czy operacyjnych np. zmiany w procesach Biura Obsługi Klienta (BOK), itd.
  3. Projektowanie oprogramowania – projektowanie architektury systemów, ich integracji, bezpieczeństwa, skalowalności, zasad kodowanie, frameworków czy interfejsu użytkownika (UI – User Interface).
  4. Wytwarzanie oprogramowania (kodowanie) – najdłuższa faza projektu realizowania wg. wybranej metodyki zarządzania projektem np. Scrum. Podczas tej fazy jest tworzony kod aplikacji zgodnie z zasadami i wymaganiami ustalonymi we wcześniejszych fazach np. tworzenie testów jednostkowych czy automatycznych, dokumentacji, itd.
  5. Integracje i testy – testowanie zarówno interfejsów, szybkości działania, wydajności, bezpieczeństwa czy poprawności integracji danych.
  6. Wdrożenie na produkcję – wdrożenie oprogramowania na produkcję zgodnie z wcześniej ustaloną strategią wdrażania np. testy AB na mniejszej ilości klientów, itd. Testowanie poprawności systemu, integracji oraz infrastruktury tele-informatycznej.
  7. Utrzymanie systemów – utrzymanie systemów łącznie z wykrywaniem i łataniem błędów, zwiększonym ruchem czy większą ilością użytkowników. Zmiany w infrastrukturze tele-informatycznej oraz zwiększanie bezpieczeństwa systemu.
  8. Dalszy rozwój systemu – procedura zgłaszania zmian rozwojowych, ich wdrożenie, testowanie i ich wpływa na działanie systemu czy integracji.
  9. Wyłączenie systemów – upgrady systemów, ich archiwizacja, wyłącznie, migracja danych, itd.

Zapraszamy do zapoznania się z naszą ofertą doradztwa technologicznego i audytów aplikacji

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 300 zadowolonych klientów

Centrum usług wspólnych (CUW) – Shared Service

Centra usług wspólnych (Shared Service Center, SSC) są bardzo popularną formą tworzenia struktur korporacyjnych wydzielając i centralizując kluczowe usługi w osobnych podmiotach. Podmioty te świadczą usługi głównie dla klienta wewnętrznego choć zawsze pojawia się strategi dywersyfikacja przychodów i otwarcie się na klienta zewnętrznego często konkurencyjnego do klienta wewnętrznego.

Najpopularniejszymi usługami świadczonymi przez tzw. CUW-y są usługi finansowo-księgowe i informatyczne z uwagi na ich skomplikowanie, czasochłonność, powtarzalność i często dużą dojrzałość procesu. Głównymi powodami powoływania shared service-ów lub jednostek BPO (Business Process Outsourcing) w Polsce są niższe koszty obsługi procesów niż w innych krajach, dostęp do wyspecjalizowanej kadry, aspekty kulturowe oraz przewidywalność gospodarcza czy prawna (!).

CUW-y informatyczne skupiają się na świadczeniu następujących usług:

  • Wytwarzanie oprogramowania
  • Utrzymanie systemów tele-informatycznych jak np. systemów SAP
  • Usługi Service Desk (Help Desk)
  • Utrzymanie infrastruktury sieciowej i tele-informatycznej

Głównymi parametrami takich usług jest cena świadczenia usługi oraz jakość świadczenia usługi SLA (Service Level Agreement). Często shared service specjalizują się w jednej usłudze np. centrum kompetencyjne SAP, które utrzymuje i rozwija systemy SAP dla całej grupy. Często centrum kompetencyjne skupia się np. tylko na wytwarzaniu oprogramowania i jego utrzymaniu.

Ostatnio bardzo popularne są shared service specjalizujące się w działaniach badawczo-rozwojowych (B+R, R&D – Research and Development).

Często wydzielenie shared service-ów lub tworzenie centrów kompetencyjnych jest elementem strategii cyfrowej transformacji a często wynika z analizy kosztów i możliwości.

Zobacz także:

Jeśli potrzebujesz wsparcia w cyfrowej transformacji, optymalizacji procesów IT zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Mikroserwisy w eCommerce – Architektura eCommerce

Mikroserwisy są podstawą architektury rozproszonej systemów zdecydowanie różniącej się od architektury monolitycznej oprogramowania. Mikroserwisy są pojedynczymi komponetntami, aplikacjami czy modułami realizującymi daną funkcjonalność lub świadczący usługi. Mikroserwisy wymieniają się danymi lub wchodzą w interakcję z innymi modułami architektury poprzez np. API (Application Programming Interface).

Mikroserwisy – korzyści

Mikroserwisy posiadają wiele korzyści np.:

  • Łatwiejsze zarządzanie architekturą oprogramowania, modułami, usługami
  • Łatwiejszy development w postaci rozwijania danych komponentów przez osobne zespoły
  • Minimalizacja błędów w innych modułach
  • Skalowanie na poziomie danej usługi nie systemu
  • Zwiększenie ciągłości biznesowej w przypadku awarii, internetu, Data Center, itd.
  • Zwiększenie wydajności systemu
  • Zmniejszenie (potencjalne) kosztów rozwojowych systemu

Mikroserwisy – wady

  • Zwiększenie stopnia trudności oprogramowania i projektu z uwagi na złożoność architektury rozproszonej (komunikacja pomiędzy usługami, itd.)
  • Zwiększenie kosztów wytworzenie i i utrzymania systemu
  • Zwiększenie skomplikowania testów usług dostawrczanych przez mikroserwisy
  • Trudniejsze wdrażania niż w architekturze monolitycznej

Mikroserwisy w eCommerce?

Mikroserwisy świetnie wpisują się w architekturę systemów eCommerce szczególnie tam gdzie jest dużo systemów takich jak sklepy internetowe B2B i B2C, pasaże handlowe, systemy wymiany danych, systemy kurierskie, systemy PIM (Product Information Management), systemy OMS (Order Management System), systemy CRM (Customer Relationship Management), systemy ERP (Enterprise Resources Management), systemy WMS (Warehouse Management System), systemy Marketplance, systemy do obsługi BOK (Biuro Obsługi Klienta), systemy kioskowe lub POS (Point of Sales) czt programy lojalnościowe. Mikroserwisy świetnie wkomponowują się w podejście Headless w CMS (Content Management System) oddzialającego backend od frontendu czy wykorzystaniu PWA (Progressive Web Application).

Jeśli potrzebujesz wsparcia w obszarze architektury eCommerce czy optymalizacji procesów eCommerce zapraszamy do kontaktu.

Zobacz naszą ofertę doradztwa:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Audyt Frontend

Frontend wraz z Backendem tworzą aplikację internetową, sklep internetowy, stronę www czy aplikację typu SaaS (Software as a Service).

Dlaczego do frontendu trzeba przyłożyć więcej wagi niż do innych części naszych systemów?

  • Frontend jest naszą wizytówką
  • Frontend zarabia dla nas pieniądze

Dlatego frontend musi mieć dopracowany UX (User interface), UI (User Interface), musi być szybki, wydajny, działający na wielu różnych ekranach (aplikacja mobilna), użyteczny dla użytkownika końcowego. Frontend jest często łączony z Backendem poprzez API (Application Programming Interface), który umożliwia podłączenie backendu do wielu frontendów np. desktop, mobile, itd.

Oferta Audytu Frontend:

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Audyt bezpieczeństwa API

Obecnie większość systemów posiada API (Application Programming Interface) lub integruje się z innymi systemami w inny sposób. API w przypadku systemów firm typu Omnichannel, eCommerce, Retail, banków, aplikacji mobilnych czy platform SaaS (Software as a Service) staje się elementem krytycznymi (bezpieczeństwo i wydajność) i naraża firmę na straty finansowe i utratę reputacji.

Projekt OWASP (Open Web Application Security Project) w 2019 r. zdefiniował następujące najważniejsze ryzyka i ataki związane z API:

  • Broken Object Level Authorization
  • Broken Authentication
  • Excessive Data Exposure
  • Lack of Resources & Rate Limiting
  • Broken Function Level Authorization
  • Mass Assignment
  • Security Misconfiguration
  • Injection
  • Improper Assets Management
  • Insufficient Logging & Monitoring

Ataki na API pozwalają na zdobycie nieautoryzowanego dostępu do danych i systemów łączenie z przejęciem całego dostępu do nich co pozwala na manipulację danymi czy wykasowanie danych. Ataki na API często wykorzystuje się w celu uzyskania dostępu do danych prywatnych celem kradzieży tożsamości (phishing) potrzebnej do zakładania fałszywych kont bankowych i innych usług. Inne przestępstwa to ujawnienie danych wrażliwych lub osób korzystających z danych usług cyfrowych. API staje się także często ofiarą ataków typów DoS (Denial of Services) lub DDoS (Distributed Denial of Services), które powodują braki odpowiedzi API dla innych usług czy użytkowników poprzez ich przeciążenie.

Zobacz naszą ofertę doradczą dla aplikacji, systemów, platform SaaS, sklepów internetowych w zakresie jakości kodu, bezpieczeństwa i wydajności:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Zwinne wytwarzanie oprogramowania Scrum i Kanban

Zwinne wytwarzanie oprogramowania (Agile Software Development) na dobre zagościło w polskich firmach. Obecnie mało, w której nie stosuje się jakiegoś “zwinnego” procesu  wytwarzania oprogramowania. Dlaczego tak się dzieje? Dlaczego firmy odchodzą od tradycyjnych metod prowadzenia projektów na rzecz bardziej elastycznych lub je łączą? Powodów jest wiele. A więc od początku.

W 2001 roku powstał manifest zwinności, który obecnie brzmi “Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.

Od tego się zaczęło. Od tamtego czasu powstało wiele odmian metodyk zwinnych takich jak XP (Extreme programming), Crystal Clear, Scrum i inne. Jednakże dopiero Scrum został tak szeroko przyjęty przez programistów i organizacje. Tzw. “wdrożenie” Scruma nie jest łatwe, gdyż zmienia on sposób myślenia i funkcjonowania nie tylko samego działu deweloperskiego, ale i całej organizacji. Scruma możemy wykorzystywać stale w procesie wytwarzania oprogramowania lub w przypadku wyjątkowo ważnych projektów, które charakteryzują się dużą zmiennością, ograniczonym czasem i obarczonych dużym ryzykiem.

Zacznijmy od najważniejszego: ludzi. Scrum składa z trzech ról: właściciela produktu (Product Owner), zespołu oraz Scrum Mastera. Właściciel produktu reprezentuje osoby zainteresowane produktem np. sponsor, zarząd, dział sprzedaży, itd. Ustala on priorytety i odbiera wytworzone produkty. Zespół deweloperski jest odpowiedzialny za wykonanie zadań i ponosi grupową odpowiedzialność za ich realizację. Zespoły budujemy w zależności od czekających nas zadań tak, aby znaleźli się w nim specjaliści o kompetencjach umożliwiających wykonanie zleconych im zadań. Scrum Master jest rolą odpowiedzialną za realizowanie całego procesu scrumowego i “ochronę” jego przed próbami łamania zasad. Ta rola nie jest ani Team Leaderem ani Project Managerem.

Zobaczmy jak wygląda proces wytwarzania oprogramowania w Scrumie:

  • Planowanie (Sprint Planning), spotkanie inicjujące, które składa się z dwóch części. Pierwsza część to prezentacja przez product ownerów zadań do wykonania, celów, priorytetów, itd. Druga część to analiza przez zespół programistyczny czasochłonności, trudności wykonania, możliwej do zastosowania technologii lub architektury. Wynikiem tego jest Sprint Backlog – lista zadań wybrana na jeden sprint z Product Backloga.
  • Codzienne spotkania (Daily Scrum lub Daily Standup), krótkie kilkuminutowe spotkania członków zespołu, zazwyczaj w godzinach porannych. Każdy z zespołu odpowiada na 3 pytania, co zrobił wczoraj, co zrobi dzisiaj i czy są tematy, które blokują jego pracę.
  • Przegląd sprintu (Sprint Review) to spotkanie pod koniec każdego sprintu, gdzie zespół oddaje wykonaną pracę w postaci działającego produktu.
  • Analiza sprintu (Sprint Retrospective) to spotkanie, na którym możemy omówić, co się nie udało podczas tego sprintu, co należy poprawić, itd. Bardzo ważne spotkanie, które często jest pomijane ze względu na brak czasu (spotkanie można realizować np., co drugi lub trzeci sprint, ale nie wolno pomijać jego zgodnie z procesem samodoskonalenia).

Zatem jak “wdrożyć” Scruma w kilku krokach:

  • Podziel ludzi na małe zespoły (kilku osobowe w zależności od skali organizacji i projektów) posiadających w sobie różne kompetencje.
  • Wyznacz rolę właściciela projektów lub zadań (Produkt Owner) oraz Scrum Mastera.
  • Podziel zadania lub projekty na mniejsze zadania, ustal z Product Ownerami ich priorytety i oszacuj potencjalny czas ich realizacji, zrób z tego kolejkę lub listę zadań (Product Backlog).
  • Wyznacz czas jednego sprintu (czas, w którym będziemy pracowali a na koniec jego oddawali zlecone zadania) zależnie od skali zadań od jednego do kilku tygodni.
  • Rozpocznij sprint zgodnie z procesem opisanym wyżej.

Co daje nam Scrum? W teorii są to: łatwość reagowania na zmiany i łatwość realizacji zadań, zwiększona produktywność i jakość, szybsze reagowanie na pojawiające się ryzyka, wcześniejsze uzyskiwanie półproduktów, poprawę komunikacji pomiędzy biznesem a działami IT, większe zaangażowanie całej organizacji w prace rozwojowe, zmniejszenie kosztów realizacji projektów i jeszcze kilka innych. Oczywiście jest to tylko teoria i wszystko zależy od ludzi i chęci zmiany aktualnej rzeczywistości w organizacji.

Czym jest Kanban i w czym może nam pomóc? Kanban wywodzi się z systemów produkcyjnych, głównie z branży motoryzacyjnej. Pozwala śledzić postępy prac nad poszczególnymi produktami na liniach montażowych. Kanban należy do tzw. systemów “ciągnionych” (pull), które różnią się od systemów “pchanych” (push) realnym zapotrzebowaniem na wytwarzanie niż z góry wytyczoną polityką produkcji. Proces wytwarzania oprogramowania może zostać porównany z linią montażową w hali produkcyjnej, dlatego Kanban idealnie nadaje się, jako technika sygnalizacyjna przy zarządzaniu realizacją zadań czy projektów.

Wszystkie zadania poruszają się zgodnie z przepływem (flowem) w jednym kierunku (np. z lewa do prawa) i przechodzą przez kolejne etapy (np. analiza, implementacja, testowanie, wdrożenie, itd.) . Każdy z etapów posiada określone zasoby (pracownicy o odpowiednich umiejętnościach) oraz możliwość przerobu (ilość możliwej do wykonania pracy w tej samej jednostce czasu). Dzięki takiemu podejściu szybko widzimy, na jakim etapie znajdują się zadania, gdzie mamy ograniczenia oraz co musimy zrobić, aby zwiększyć przerób, czyli produkcję oprogramowania.

Kanban posiada kilka podstawowych zasad:

  • Wizualizacja – stworzenie i rozrysowanie (na tablicy lub za pomocą oprogramowania) procesu wytwarzania oprogramowania ze statusami działań np. analiza, wytwarzanie, testowanie, wdrażanie, zadania skończone.
  • Limit pracy w toku (WIP – Work in Progress) – nie możemy pracować nad większą liczbą zadań niż jesteśmy w stanie wykonać w tej samej jednostce czasu oraz jeśli nie dostaliśmy zlecenia na wykonanie pracy przez jednostkę zlecającą. Jest to zasada wywodząca się z systemów “ciągnionych” (pull).
  • Zarządzanie strumieniem – monitorowanie i raportowanie o etapach wykonywania zadań, prędkości i płynności wykonywania zadań. Idealny proces charakteryzuje się dużą prędkością wykonywania zadań i płynnością oraz przewidywalnością.


Jak zacząć? Zastosowanie Kanbana jest bardzo proste. Poniżej kilka kroków, jakie należy uczynić, aby móc sprawnie zarządzać zadaniami w procesie wytwarzania oprogramowania.

  • Rozrysuj aktualny proces wytwarzania oprogramowania np. na tablicy lub dużej powieszonej na ścianie kartce papieru. Kolumny będą oznaczały kolejne elementy procesu.
  • W pierwszej kolumnie (np. nazwanej listą zadań, backlog-iem lub wish listą) umieść karteczki z zadaniami. Powstanie kolejka zadań. Nadaj im priorytety. Podziel zadania na kategorie zadań np. błędy, zadania, poprawki, itd.
  • Nazwij kolejne kolumny np. analiza, programowanie, testowanie, wdrażanie i zadania skończone.
  • Określ możliwy przerób na każdym etapie (tzw. WIP) np., jeśli posiadamy jednego testera to możemy przyjąć, że na etapie testowania będziemy mogli równocześnie testować tylko jedno zadanie.
  • Podziel oznaczone już etapy (kolumny) na dwa statusy: w trakcie, skończone.
  • Zacznij działać. Pobieraj zadania z kolejki zgodnie z możliwościami przerobu (WIP). Przesuwaj zadania zgodnie ze zmianami statusów do lewa do prawa, aż do kolumny zadania skończone (wdrożone).

Co dalej? Kanban pozwala na analizę czasu potrzebnego na wykonania zadań. Dzięki takiej wiedzy i grupowaniu zadań nie musimy szacować czasochłonności wykonania zadań a określać wielkość zadań za pomocą prostych miar np. duże, małe, średnie. Zaoszczędzi to nam bardzo dużo czasu na estymację, która i tak będzie błędna. A co w przypadku pisania oprogramowania dla klienta zewnętrznego? Tutaj warto przyjrzeć się połączeniu Scruma i Kanbana, co zrobimy w dalszej części. Kanban pozwala wykrywać wąskie gardła w procesie od pojawienia się pomysłu, aż do wdrożenia oprogramowania. Często wąskie gardła znajdują się poza procesem wytwarzania oprogramowania np. w dziale biznesowym, który jest odpowiedzialny za testy akceptacyjne wytworzonych produktów.

Kanban pozwala zmniejszyć skutki wielozadaniowości poprzez stosowanie limitów WIP. Pozwala to na zajmowanie się zadaniami, które w rzeczywistości mają wysoki priorytet i które możemy rzeczywiście wykonać w jednej jednostce czasu.

Proces wytwarzania powinien charakteryzować się też płynnością wykonywania zadań. Monitorujmy zatem  i udoskonalajmy wszystkie elementy procesu. Pozwoli to w przyszłości do osiągnięcia dużej prędkości wytwarzania oprogramowania, unikania wąskich gardeł i nie tracenia cennego czasu.

Kolejne kroki? Mamy już działający Scrum. Widzimy także tablicę Kanbana. Jak to teraz połączyć i co dzięki temu zyskamy? Scrum działa w określonych okresach czasu tzw. iteracjach. Kanban to zmienia mówiąc, że zasoby są wolne i domagają się otrzymania kolejnych zadań. Praca w Scrumbanie zaczyna przypominać taśmociąg, który pracuje niezależnie od okresu czasu. Dzięki takiemu podejściu możemy wykonać więcej zadań niż w typowym sprincie. Możemy także mniej uwagi przywiązywać do estymacji czasu wykonania a bardziej bazować na priorytetach i kolejce. W praktyce w niedługim czasie zobaczymy, że wykonujemy więcej zadań niż pracując w typowym Scrumie.

Jakie są różnice pomiędzy Scrumem a Scrumbanem? Nie ograniczamy się do sprintu. Bierzemy pierwsze zadanie z kolejki. Tablica Kanbana może być stosowana dla wielu zespołów a także dla całych firm. W przypadku tablicy Scruma, korzysta z niej tylko zespół scrumowy. Jak widzimy tablica Kanbana poprawia komunikację i poszerza wiedzę o innych zadaniach i projektach wykonywanych przez inne zespoły, niekoniecznie informatyczne. W Scrumbanie nie patrzymy na wykres spalania (burndown chart) a bardziej na czas wykonania zadania. A co z codziennymi spotkaniami, sprint planningiem czy sprint review? Polecam kontynuowanie codziennych stand-upów, planowanie tylko wtedy, kiedy jest to potrzebne, a przeglądy regularnie, co kilka tygodni w z góry ustalonym terminie. Zachęcam do eksperymentowania i procesu ciągłego doskonalenia. Jestem też zwolennikiem adoptowania najlepszych elementów z różnych metodologii do istniejącej organizacji np. elementów Scruma, Princa2, PMI, CCPM lub Kanbana.

Zobacz naszą ofertę doradczą:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Metodyka rozwoju oprogramowania DevOps

Nazwa DevOps pochodzi od słów „development” czyli wytwarzanie oprogramowania i „operations” czyli operacje, eksploatacji systemów. Metodyka DevOps ma połączyć światy wytwarzania, testowania, wdrażania, administrowania i utrzymania, często inne, o innych celach i kompetencjach. Kładzie ona nacisk na komunikację pomiędzy działem utrzymania (administratorami systemów) oraz programistów i testerów oprogramowania.

Włączenie administratorów do rozwoju oprogramowania ma ewidentne zalety:

  • Pozwala na szybsze wdrażanie zmian „na produkcję” dzięki czemu biznes osiąga więcej korzyści np. częstsze wdrożenia zmian w platformie eCommerce (sklep internetowy) lub na platformie SaaS
  • Pozwala na lepsze wykorzystaniu posiadanych zasobów serwerowych i obniżeniu kosztów
  • Zwiększa wydajność i bezpieczeństwo systemów obniżając koszty utrzymania.

Metoda DevOps wykorzystuje szeroko zdalne narzędzia do komunikacji pomiędzy członkami zespołu jak wiki, wideokonferencje, czaty, itd. Dlatego bardzo dobrze sprawdza się w okresie pandemii wirusa corona Covid-19.

Metodyka i inżynierowie DevOps lubą pracować ze zwinnymi metodykami wytwarzania oprogramowania (Agile np. Scrum) czy z środowiskami chmurowymi (np. Microsoft Azure, Google GCP, Amazon AWS).

Metodyka DevOps pozwala na lepsze zarządzania cyklem życia aplikacji (oprogramowania), gdzie już w fazie planowania przewidujemy przyszłość i rozwój systemu w kolejnych latach.

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

IT Governance (Ład Korporacyjny IT)

Ład korporacyjny IT (IT Governanace) czyli uporządkowany zbiór zasad opisujących procesy, procedury i zasady IT panujące w organizacji. Każdy dział IT dzięki ładowi korporacyjnemu posiada dobrze opisane i działające dobre praktyki wspierające biznes. Ład korporacyjny IT zarządza także finansami np. zwrotami z inwestycji, ludźmi jak umowy z podwykonawcami czy zarządzanie zarządza ryzykiem i ciągłością biznesową (Business Continuity).

Przykładem ładu korporacyjnego jest standard COBIT (Control Objectives for Information and Related Technologies), który definiuje procesy zarządzania usługami IT. w Architekturze korporacyjnej IT COBIT często jest łączony z frameworkiem ITIL (Information Technology Infrastructure Library), który definiuje cykl życia poszczególnych usług informatycznych i ich najlepszych praktyk. Inny framework powszechnie stosowany to TOGAF (The Open Group Architecture Framework).

Audyt IT Governance (Audyt ładu korporacyjnego IT) pozwala na:

  • Ocena dojrzałości organizacji IT
  • Sprawdzenie efektywności kosztów procesów IT
  • Sprawdzenie efektywności zarządzania projektami
  • Sprawdzenie efektywności zarządzania ludźmi
  • Sprawdzenie efektywności zarządzania dostawcami
  • Sprawdzenie efektywności wspierania biznesu przez IT
  • Sprawdzenie ryzyka i jego wielkości w systemach IT
  • Sprawdzenie stanów backupów i procedur odtworzenia do awarii
  • Sprawdzenie efektywności polityki bezpieczeństwa i jej wdrożenia
  • Sprawdzenie efektywności funkcjonowania IT na tle innych działów, działań, strategii rozwoju organizacji
  • Ocena długu technologicznego
  • Ocena prawna umów, RODO, audyt licencji

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Systemy Web Content Management (WCM)

Systemy WCM (Web Content Management) pozwalają na tworzenie, przechowywanie i udostępnianie różnego contentu w różnych kanałach cyfrowych takich jak sklepy internetowe, portale informacyjne,strony internetowe, aplikacje mobilne, intranet wewnętrzny, itd.

Popularnymi systemami do zarządzania contentem są: Adobe, Sitecore, Acquia, Episerver, Oracle Content and Experience (OCE), Kentico, OpenText, Automattic, Progress, Crownpeak, CireMedia, e-Spirit, Bloomreach, SDL, WP Engine (WordPress – open source), Squiz, Magnolia czy eZ.

Na co powinniśmy zwrócić uwagę przy wyborze platformy WCM:

  • Multisite i multilanguage management
  • Moduł analityczny i raportowy
  • Łatwość projektowania i zmian
  • Łatwość tworzenia contentu
  • Metadata management
  • Cena
  • Ceny wsparcia posprzedażowego
  • Dostępność lokalnych partnerów
  • itd.

Jeśli potrzebujesz wsparcia w wyborze systemów WCM oraz innych (zobacz ofertę doradczą na systemy ERP, CRM, WMS, itd.) lub wyborze dostawcy zapraszamy do kontaktu.


Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów



Audyt Code Review (Audyt Inspekcji Kodu)

Code Review to przegląd (inspekcja) kodu napisanego przez programistę przez innego programistę, audytora, senor developera, architekta czy innego członka zespołu, który ma taką przypisaną rolę i kompetencje do przeprowadzenia audytu. Code Review przeprowadzamy przed dodaniem kodu do repozytorium, przed testowaniem.

Czemu ma służyć Code Review?

Code Review pozwala na zwiększenie jakości pisanego kodu poprzez ciągłe jego sprawdzania, udoskonalanie.

Jakie są wady Code Review?

Największą to czas powięcony na sprawdzanie kodu zarówno czas programistów jak i czas oddania kodu, aplikacji czy systemu na produkcję. Dlatego często code review jest wykonywany sporadycznie lub nawet bardzo rzadko.

Jakie są korzyści stosowania stałego Code Review?

  • Łatwość czytania kodu przez innych programistów – czyli łatwiejsze zmiany, łatwiejsze wprowadzenie nowych osób do zespołu, itd.
  • Świetna nauka i wymiana doświadczeń pomiędzy członkami zespołu o różnym doświadczeniu i stażu pracy nad systemem.
  • Wyłapanie błędów lub znajdywanie prostszych metod kodowania.
  • Dojrzałość systemów wymaga najlepszych standardów i praktyk, a zatem Code Review też jest potrzebny.

Audyt Code Review

GoTechnologies wykonuje Audyty oraz Doradztwo Code Review pod kątem najlepszych standardów przeglądu kodu.

Zobacz naszą ofertę na Audyt Aplikacji, Audyt kodu źródłowego, Audyt architektury systemów

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów