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

Architektura Cloud Native

Cloud Native to technologia wykorzystania chmury przy tworzeniu własnych aplikacji. Technologia korzystające z mikroserwisów, kontenerów czy usług bezserwerowych tzw. Serverless.

Planując architekturę Cloud Native należy zacząć m.in od pytania o stopień „przenaszalności” aplikacji pomiędzy dostawcami chmury (Vendor-lock). Kolejne pytania dotyczą apliakacji, które będziemy tworzyli lub przenosili. Dostawca chmury powinien być dopasowany do tych aplikacji, aby wykorzystać najlepiej ich możliwości.

W przypadku chęci uniezależnienia się od dostawcy chmury często stosuje się popularne kontenery np. na Kubernetes czy Amazon Elastic Container Service (Docker). Kontenery pozwalają na łatwą przenaszalność aplikacji pomiędzy środowiskami, budowanie mikroserwisów czy niemal nieograniczoną skalowalność.

Innym typem budowania aplikacji dla technologii Cloud Native jest wykorzystanie funkcjonalności chmur typu Serverless. Usługi tego typu są dostarczane przez wszystkich dostawców chmur jak AWS, Google GCP czy Microsoft Azure.

Aplikacje Cloud Native (Native Cloud Application – NCA) są tworzone zgodnie z zasadą rozdzielania zadań na usługi (mikroserwisy, mikrousługi) i zgodnie z zasadą oddzielania ich od infrastruktury np. z wykorzystaniem kontenerów czy funkcji serverless.

Jeśli potrzebujesz wsparcia w architekturze systemów czy audycie swoich aplikacji zapraszamy do kontaktu.

Zobacz także: doradztwo strategiczne IT

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Startupy a kryzysy technologiczne

Startupy to technologia, a technologia wymaga posiadania odpowiednich kompetencji i ciągłego ich rozwijania. Technologia musi być wydajna oraz spełniać oczekiwania klienta. Produkt startupu musi działać, ale tak jak tego sobie życzy klient. Startupy tworzą zarówno aplikacje mobilne, sklepy internetowe, systemy SaaS (Software as a Service), platformy Marketplace, urządzenia IoT czy inne urządzenia hardwarowe. Wszystkie te produkty wymagają wysokiej dojrzałości technologicznej. Wiedza członków startupu czy założycieli (founderów) często koncentruje się na sprzedaży, klientach czy marketingu lub na aspekcie technologicznym. Idealnym połączaniem jest, kiedy zespół założycielski posiadający wszystkie te kompetencje. Oczywiście faza początkowa rozwoju startupu charakteryzuje się posiadaniem małego budżetu, małej ilości czasu na dopracowanie produktu technologicznego oraz braki zasobowe i kompetencyjne. Z tego też powodu kryzysy technologiczne przychodzą szybciej niż nam się wydaje.

Jakie kryzysy technologiczne przechodzą startupy?

Poniżej lista zaobserwowanych kryzysów technologicznych w startupach fazy seed i eary grow:

  • Wydajność aplikacji, sklepu czy platformy SaaS – brak myślenia co będzie za rok, jak zwiększy się liczba danych czy klientów. Wymaga często zmiany infrastruktury lub co trudniejsze architektury systemów – zobacz doradztwo w obszarze wydajności, doradztwo w zakresie cloud, doradztwo w zakresie architektury
  • Hardware – częsty brak budżetu na wersję nr 2 prototypu związaną ze zmianami technologicznymi, potrzebami klientów czy trendami
  • Brak bezpieczeństwa danych i systemów – zobacz doradztwo w obszarze bezpieczeństwa
  • Odejście kluczowej osoby takiej jak CTO czy senior developer
  • Brak dokumentacji systemu utrudniający wdrożenie nowych członków zespołu
  • Brak skutecznego zarządzania projektami czy zmianami np. pseudo agile podejście (Scrum) – zobacz doradztwo w obszarze zarządzania projektami
  • Duży i często niespodziewany przyrost danych Big Data powodujący problemy z bazami danych i aplikacjami – zobacz doradztwo Big Data
  • Użyteczność interfejsu (UX – User Experience, UI – User Interface) – zobacz audyty UX, UI, eCommerce
  • Brak regularnych upgradów wykorzystywanych frameworków powodujących dług technologiczny trudny do naprawy – zobacz doradztwo dług technologiczny
  • Brak przyjętych zasad kodowania, architektury czy testowania
  • Brak API
  • itd.

Zobacz więcej o doradztwie technologicznym dla Startupów

Jeśli potrzebujesz wsparcia technologicznego i procesowego w Twoim startupie, zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Wydajność w systemach i aplikacjach

Wydajność jest jednym z ważniejszych elementów funkcjonowania systemów, aplikacji czy usług informatycznych. Problemy z wydajnością są odczuwalne od razu, widoczne przez klienta i potrafiące wpłynąć na nasze przychody czy zyski np. poprzez niezrealizowanie umownego poziomu SLA (Service Level Agreement).

Problemy z wydajnością mogą dotyczyć:

  • Niepoprawnie stworzonej aplikacji lub zapytań sql do bazy
  • Ataków na dostępność i wydajność usług (Ataki DoS i DDos – Denial of Service)
  • Niepoprawnych konfiguracji bazy danych
  • Braki w zasobach sprzętowych serwerów czy macierzy
  • Niepoprawne konfiguracje serwerów i ich usług

Najczęstsze problemy spotykany w ostatnim roku związane z systemami i wydajnością:

  • Mało wydajne środowisko serwerowe
  • Brak rozdzielanie serwerów bazodanowych od aplikacyjnych
  • Pojedyncze bazy danych, brak separacji
  • Niewydajne API
  • Niepoprawne konfiguracja baz danych np. mała alokacja pamięci RAM
  • Niezoptymalizowane zapytania do baz danych
  • Brak wykorzystania cachowania
  • Brak wykorzystania narzędzi typu CDN czy Cloud dla aplikacji internetowych
  • Brak wykorzystania modularności czy mikrousług w architekturze platform czy sklepów internetowych
  • Problemy wydajnościowe na poziomie intergacji i wymiany danych pomiędzy sklepami internetowymi a systemami ERP czy WMS.

Zobacz także:

Jeśli potrzebujesz wsparcia w zakresie architektury systemów, poprawy wydajności czy audycie kodu źródłowego zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Smart Home – inteligentne domy

Inteligentne domy (Smart Homes) to trend, który rozpoczął się na dobre kilka lat temu m.in. w Polsce z uwagi na dostępność w kraju internetu, szczególnie na peryferiach i wioskach, gdzie dużo Polaków zaczęło stawiać swoje domy, z dala od zgiełku miejskiego. Drugą przyczyną rozwoju urządzeń dla inteligentnych domów jest dostępność technologii, ciągły spadek ich cen oraz coraz szersza gama produktów, które są prostsze w użyciu czy montażu. Produkty te są dostarczane przez duże firmy zachodnie i polskie jak i startupy technologiczne, których liczba ciągle rośnie. Na rynku widoczne są też projekty typu spin-off czy Joint Venture firm, których efektem są spółki czy produkty dla inteligentnych domów czy inteligentnych miast (Smart City).

Dostęp do internetu, także 5G (zobacz Startupy 5G) spowodował rozkwit urządzeń Internetu Rzeczy (IoTInternet of Things). Za pomocą aplikacji mobilnej możemy sterować urządzeniami na odległość np. ogrzewaniem, otwieraniem okien czy podlewaniem trawnika. A nasza lodówka potrafi zaproponować nam produkty do kupienia.

Dane z urządzeń Internetu Rzeczy są zazwyczaj przechowywane w chmurze (Cloud). Nowe urządzenia potrafią przewidywać nasze zachowania za pomocą algorytmów sztucznej inteligencji (AIArtificial Intelligence) wraz uczeniem maszynowym (Machine i Deep Learning). Rodzi to nowe obszary do innowacji oraz zagrożenia. Największymi zagrożeniami jest dostęp do danych, nieuprawnione działania hackerów czy złodziei. Dzięki danym mogą przewidzieć czy ktoś jest w domu, kiedy może wrócić do domu, jakie są zabezpieczenia, itd.

Jeśli jesteś Startupem technologicznym, który tworzy innowacyjne produkty czy Software Housem i masz wyzwania technologiczne i biznesowe dla swojego produktu zapraszamy do kontaktu.

Zobacz naszą ofertę doradztwa technologicznego:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Poziom gotowości technologicznej TRL w Startupach

Poziom gotowości startupu zarówno rozwoju produktu jak i gotowości do komercjalizacji TRL (Technology Readiness Level) określa się w skali od 1 do 9. Skala jeden to ocena wstępnej koncepcji, walidacja pomysłu, realności wdrożenia, natomiast skala dziewięć to gotowość produktu do sprzedaży (po wszystkich testach, certyfikacji, itd.). TRL określa zatem poziom dojrzałości produktu do jego komercjalizacji. Czym wyżej w skali tym mniejsze ryzyko niepowodzenia i szybszy czas rozpoczęcia sprzedaży produktu.

Skala ta ułatwia zewnętrznym inwestorom śledzenie postępu rozwoju produktów i jest pomocnym narzędziem i wskaźnikiem rozwoju KPI (Key Performance Indicator). TRL jest powszechnie stosowany nie tylko w Polsce, ale także jest standardem w Unii Europejskiej w Stanach Zjednoczonych, gdzie został pierwotnie wymyślony przez NASA w latach 70-tych. Z punktu widzenia inwestora czym wyższym TRL tym większa szansa na sukces i mniejsze ryzyko inwestycyjne. Oczywiście należy pamiętać także o własnym IT Due Diligence, nie zawsze founderzy rozumieją TRL, a wręcz podwyższają skalę dojrzałości produktu.

Skalę TRL można podzielić na trzy grupy:

  • TRL 1: Prace koncepcyjne, analiza pomysłu, produktu, realności jego stworzenia
  • TRL 2-6: Badania przemysłowe nad produktem
  • TRL 7-9: Prace rozwojowe nad produktem

Skala TRL w NCBiR:

  • TRL 1: Zaobserwowano i opisano podstawowe zasady danego zjawiska – najniższy poziom gotowości technologii, oznaczający rozpoczęcie badań naukowych w celu wykorzystania ich wyników w przyszłych zastosowaniach. Zalicza się do nich między innymi badania naukowe nad podstawowymi właściwościami technologii.
  • TRL 2: Określono koncepcję technologii lub jej przyszłe zastosowanie. Oznacza to rozpoczęcie procesu poszukiwania potencjalnego zastosowania technologii. Od momentu zaobserwowania podstawowych zasad opisujących nową technologię można postulować praktyczne jej zastosowanie, które jest oparte na przewidywaniach. Nie istnieje jeszcze żaden dowód lub szczegółowa analiza potwierdzająca przyjęte założenia.
  • TRL 3: Potwierdzono analitycznie i eksperymentalnie krytyczne funkcje lub koncepcje technologii. Oznacza to przeprowadzenie badań analitycznych i laboratoryjnych, mających na celu potwierdzenie przewidywań badań naukowych wybranych elementów technologii. Zalicza się do nich komponenty, które nie są jeszcze zintegrowane w całość lub też nie są reprezentatywne dla całej technologii.
  • TRL 4: Zweryfikowano komponenty technologii lub podstawowe jej podsystemy w warunkach laboratoryjnych. Proces ten oznacza, że podstawowe komponenty technologii zostały zintegrowane. Zalicza się do nich zintegrowane „ad hoc” modele w laboratorium. Uzyskano ogólne odwzorowanie docelowego systemu w warunkach laboratoryjnych.
  • TRL 5: Zweryfikowano komponenty lub podstawowe podsystemy technologii w środowisku zbliżonym do rzeczywistego. Podstawowe komponenty technologii są zintegrowane z rzeczywistymi elementami wspomagającymi. Technologia może być przetestowana w symulowanych warunkach operacyjnych.
  • TRL 6: Dokonano demonstracji prototypu lub modelu systemu albo podsystemu technologii w warunkach zbliżonych do rzeczywistych. Oznacza to, że przebadano reprezentatywny model lub prototyp systemu, który jest znacznie bardziej zaawansowany od badanego na poziomie V, w warunkach zbliżonych do rzeczywistych. Do badań na tym poziomie zalicza się badania prototypu w warunkach laboratoryjnych odwzorowujących z dużą wiernością warunki rzeczywiste lub w symulowanych warunkach operacyjnych.
  • TRL 7: Dokonano demonstracji prototypu technologii w warunkach operacyjnych. Prototyp jest już prawie na poziomie systemu operacyjnego. Poziom ten reprezentuje znaczący postęp w odniesieniu do poziomu VI i wymaga zademonstrowania, że rozwijana technologia jest możliwa do zastosowania w warunkach operacyjnych. Do badań na tym poziomie zalicza się badania prototypów na tzw. platformach badawczych.
  • TRL 8: Zakończono badania i demonstrację ostatecznej formy technologii. Oznacza to, że potwierdzono, że docelowy poziom technologii został osiągnięty i technologia może być zastosowana w przewidywanych dla niej warunkach. Praktycznie poziom ten reprezentuje koniec demonstracji. Przykłady obejmują badania i ocenę systemów w celu potwierdzenia spełnienia założeń projektowych, włączając w to założenia odnoszące się do zabezpieczenia logistycznego i szkolenia.
  • TRL 9: Sprawdzenie technologii w warunkach rzeczywistych odniosło zamierzony efekt. Wskazuje to, że demonstrowana technologia jest już w ostatecznej formie i może zostać zaimplementowana w docelowym systemie. Między innymi dotyczy to wykorzystania opracowanych systemów w warunkach rzeczywistych

Zobacz naszą ofertę doradczą dla startupów i funduszy Venture Capital:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 300 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

Progressive Web Application (PWA)

Progressive Web Application (PWA) jest nowym standardem łączącym zalety stron internetowych i aplikacji mobilnych. Jest następcą standardu RWD (Responsive Web Design) czyli responsywnych stron internetowych dostosowujących się do różnych urządzeń szczególnie mobilnych takich jak smartphone czy tablety.

Dzięki PWA strony internetowe mogą zachowywać się tak jakby były aplikacją mobilną. Są szybkie, dostosowane do ekranu urządzenia mobilnego, z ikonką aplikacji na pulpicie czy z trybem pełnoekranowym bez menu przeglądarki. Frontend PWA może także cashować odwiedzane strony i działać offline w przypadku braku internetu lub jego zaniku. Strony PWA cechują się także lepszym interfejsem (UIUser Interface) bardziej dostosowanym do użytkownika (UXUser Experience).

Jeśli wahasz się czy wybrać PWA, RWD przy Twoim kolejnym redesignie strony www czy sklepu internetowego zapraszamy do kontaktu. Pomagamy wybrać technologię, wspieramy przy wyborze najlepszego Software House-u, wspieramy w project managemencie kluczowych projektów.

Zobacz także naszą ofertę doradztwa technologicznego:


Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Zasady kodowania w aplikacjach

Konwencje / standardy / zasady kodowania są niezbędnym elementem w poprawnym kodowaniu. To jak jazda samochodem z wiedzą o zasadach ruchu drogowego lub bez niego. Zasady kodowania pozwalają na pisanie kodu przez różnych programistów w ten sam sposób, dzięki temu łatwiej można go modyfikować np. poprzez nowych członków zespołu programistycznego. Dodatkowo jeśli korzystamy z zewnętrznych zasobów np. z Software House-u to jasne, z góry ustalone i zaakceptowane przez zespół zasady pomagają we wspólnej pracy. Stosowanie standardów kodowania powoduje też mniejsze starzenie się aplikacji, a dług technologiczny jest mniejszy.

Przykładowe zasady kodowania to:

  • Zasady dotyczące formatowania kodu – dla łatwej czytelności kodu źródłowego np. szerokość wcięć, maksymalna długość wierszy czy liczba pustych miejsc pomiędzy klasami czy funkcjami.
  • Konwencje nazewnicze – zarówno plików, funkcji, klas, zmiennych, modułów, przestrzeni nazw, itd.
  • Komentowanie kodu – bardzo ważny, a często zaniedbywany element zasad dobrego kodowania. Zasady opisywania algorytmów, czy komentowania zmian.
  • Konstrukcje programistyczne – zasady dla danego języka programistycznego.

Zobacz naszą ofertę doradczą w zakresie wytwarzania aplikacji:


Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów

Elektroniczny Kanban na Produkcji

Kanban (jeden z elementów Lean Managementu) jest metodą sterowania procesami produkcji, która opiera się na realnym zużyciu materiałów na linii produkcyjnej. Kanban inaczej jest nazywany systemem ssącym. Jednym z głównych celów wymyślenia metody Kanban była potrzeba zminimalizowania materiałów i surowców na produkcji. W tej metodzie materiał na produkcję jest dostarczany zgodnie z potrzebą i tzw. „sygnałem kanban” z linii produkcyjnej.

Tradycyjnie Kanban jest zwykłą kartką papieru z takimi informacjami jak nazwa lub numer potrzebnego elementu, ilość, adres składowania, lokalizacja procesu, któremu dane elementy są potrzebne, itd. „Nowocześniejsze” kartki posiadają kody kreskowe celem śledzenia towarów, przeksięgowań, itd.

Elektroniczny kanban to przeniesienie zleceń kanban do sieci i przekazywanie ich do odpowiednich miejsc i operatorów, gdzie są one przyjmowane, akceptowane i wykonywane. Elektroniczny Kanban umożliwia także zarządzanie priorytetami i zmianami w kolejce kanbanów.

Elektroniczny kanban może (lub nie musi) być zintegrowany z innymi systemami jak np. systemem ERP (np. automatyczne przeksięgowania towarów), systemami Andon informującymi o pojawieniu się zlecenia (dashboard, sygnały świetlne i dźwiękowe), systemem APS (Advanced Planning and Scheduling), MES (Manufacturing Execution System) czy MRP ( Manufacturing Resource Planning).

Jeśli potrzebujesz doradztwa w zakresie zaprojektowania systemu elektronicznego Kanbana lub optymalizacji procesów intralogistycznych zapraszamy do kontaktu.

Zobacz naszą ofertę doradczą dla Przemysłu, Automotive i Logistyki:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów