Efektywność i technologia

Metodyka

Zdefiniowana i wypracowana na przestrzeni lat metodyka pozwoliła nam z sukcesem zakończyć dziesiątki projektów — od relatywnie prostych interfejsów, mikroserwisów lub nowych funkcjonalności istniejących aplikacji, poprzez większe moduły, po złożone systemy wspierające krytyczne procesy biznesowe dużych przedsiębiorstw telekomunikacyjnych. Jasno zdefiniowane standardy dotyczące analizy, projektowania, tworzenia kodu oraz utrzymania aplikacji, w połączeniu z zestawem gotowych komponentów i rozwiązań, pozwalają na zachowanie wysokiej, przewidywalnej jakości oraz dokładną estymację kosztów i czasu niezbędnego do realizacji przedsięwzięć.

Continuous Development with Prototyping

To stosowane przez nas podejście do tworzenia oprogramowania, w którym rozwój aplikacji odbywa się w sposób ciągły, z jednoczesnym tworzeniem prototypów na każdym etapie. Prototypy pozwalają szybko testować pomysły, zbierać informację zwrotną i iteracyjnie udoskonalać produkt, co skraca czas wdrożenia i minimalizuje ryzyko błędów projektowych. Takie podejście wspiera elastyczność i bliską współpracę z użytkownikami końcowymi.

Zarządzanie złożonością

Większość aplikacji biznesowych jest oprogramowaniem złożonym, obsługującym wiele elementów procesu biznesowego, dotyczącego wielu zależnych od siebie artefaktów (np. klient, umowa, faktura, usługa, produkt, adres i setki innych).
Zachowanie logicznej spójności oraz jasnych zależności pomiędzy elementami oprogramowania są czynnikami mającymi bezpośredni wpływ na jego łatwe utrzymanie, unikanie błędów oraz łatwy, długoterminowy rozwój. Unikamy efektu szybkiego starzenia się produktu, prowadzącego do sytuacji, gdy jego dostosowywanie do zmiennych warunków biznesowych zaczyna generować niewspółmiernie wysokie koszty oraz ryzyko.

  • Enkapsulacja logiki biznesowej – pojęcie to odnosi się do podziału całości implementowanej logiki biznesowej na niewielkie, spójne i łatwo opisywalne moduły, zawierające różnego rodzaju niezbędne elementy oprogramowania (tabele, operacje, formatki itp.). Moduły takie, jako zespół, mogą implementować wysoką złożoność, zachowując jednak swoją jednostkową prostotę i zrozumiałość, zyskując tym samym jedną z cech mikroserwisów.
  • Przestrzenie nazw – ten istotny element metodyki organizuje wspomniane wyżej moduły i ich zawartość w drzewiasto zorganizowaną strukturę (moduły → podmoduły) z jasno określonymi zasadami jednoznacznego nazewnictwa wszystkich elementów oprogramowania.

Model danych

Centralnym i najistotniejszym elementem większości typowych aplikacji biznesowych jest baza danych, a tak naprawdę — logika i jakość danych w niej gromadzonych.
To dane opisują rzeczywistość biznesową, stanowiąc w ten sposób największą wartość i sens istnienia aplikacji. Jest to powodem naszego szczególnego podejścia do projektowania ich struktury, czyli modelu danych.  Mimo iż stosujemy dobrze znaną notację opartą o język UML (kiedyś Oracle® Case ERD), to wykształciliśmy również dodatkowe, bardziej szczegółowe metody opisu modelu, spójne oczywiście ze wspomnianą wyżej koncepcją przestrzeni nazw.

Architektura systemu aplikacji

Różnego rodzaju zagadnienia mogą wymagać zastosowania specyficznej architektury aplikacji, jednak w większości typowych wymagań, stosujemy dobrze sprawdzone i efektywne podejście, na które składają się poniższe elementy pojedynczego systemu aplikacji:

  • Interfejs użytkownika (front-end) – czyli część wizualna z której bezpośrednio korzysta użytkownik końcowy. Jest to najczęściej aplikacja sieci web dostępna w wszystkich popularnych przeglądarkach z możliwością przygotowania wersji dostępnej w postaci aplikacji mobilnej. System aplikacji może zawierać dowolną ilość interfejsów użytkownika dedykowanych dla poszczególnych ich grup i ról. Dodatkowo dbamy o bezpieczną autentykacje (np. dwuetapową) oraz szczegółowy system autoryzacji dostępu do poszczególnych funkcjonalności aplikacji.
  • Warstwa pośrednia (middleware) – warstwa zawierająca serwery odpowiedzialne za udostępnianie aplikacji, dostarczanie danych oraz ich modyfikację na podstawie żądań użytkownika, po uprzedniej weryfikacji jego uprawnień. W tej warstwie opcjonalnie implementowana jest również logika biznesowa, zgodnie z którą przetwarzane są dane. W środowisku produkcyjnym często występuje wiele serwerów aplikacji działających w ramach tzw. klastra, który zapewnia ciągłość działania aplikacji w przypadku awarii jednego z serwerów, zwiększa wydajność środowiska lub pełni obie te funkcje jednocześnie.
  • Baza danych – serwer bazy danych stanowi kluczowy element tzw. back-endu, czyli najgłębszej warstwy aplikacji. Przechowuje on wszystkie zgromadzone informacje, zgodnie z zdefiniowanym modelem danych. Dodawanie, udostępnianie i modyfikacja danych, odbywa się poprzez wywoływanie, realizujących logikę biznesową, procedur i funkcji zaimplementowanych w warstwie pośredniej lub bezpośrednio po stronie samej bazy danych. Druga opcja umożliwia zastosowanie zaawansowanych metod optymalizacji oraz zapewnia łatwą kontrolę wydajności systemu.
  • Procesy tła – doskonała większość zachodzących w systemie aplikacji procesów, jest inicjowana za pośrednictwem interfejsu użytkownika lub interakcją z innymi systemami. Istnieje jednak grupa zadań, które muszą być wykonywane automatycznie, czyli w określonym interwale czasu a nie na skutek bezpośredniej zewnętrznej aktywności. Przykładem może być konieczność automatycznego anulowania nieopłaconych zamówień po określonym czasie braku aktywności klienta czy generowanie i dystrybucja dziennych raportów. Aktywności takie nazywamy procesami tła, które muszą być jasno zdefiniowane oraz uruchamiane w sposób niezawodny i transparentny, co uzyskujemy poprzez stosowanie odpowiednich narzędzi monitoringu i automatycznych powiadomień.
  • Integracja – w rzeczywistych środowiskach biznesowych, konieczność integracji z innymi systemami jest jednym ze standardowych wymagań. Stosowana przez nas metodyka a szczególnie jej część odnosząca się do enkapsulacji logiki biznesowej, sprawia, że ów proces jest naturalny i nieobarczony wysokimi kosztami. Przyczynia się do tego również sama architektura aplikacji, umożliwiająca stosowanie szerokiego spektrum technologii integracyjnych zarówno w warstwie pośredniej jak i po stronie bazy danych.

Wzorce projektowe

Wielokrotna implementacja szerokiej gamy wymagań w ramach różnych projektów pozwoliła nam na identyfikację podobieństw i zdefiniowanie standardów implementacji wielu z nich. Podejście to drastycznie skraca czas oraz minimalizuje koszt developmentu aplikacji od zera lub implementacji nowych funkcjonalności w istniejącej, przy zachowaniu wysokich standardów jakości.

Testy

Istnieje wiele strategii testowania oprogramowania i choć różnią się one stosowanymi narzędziami oraz angażowanymi zasobami (w tym ludzkimi), ich cel jest jeden — niezawodność działania produktu końcowego. Spotykamy się ostatnio z tendencją całkowitego przesuwania ciężaru odpowiedzialności za jakość właśnie na fazę testów, przeprowadzanych zgodnie z predefiniowanymi scenariuszami testowymi. Prowadzi to niestety do sytuacji, w której aplikacja raportuje błąd, ponieważ pewien specyficzny przypadek użycia nie został przewidziany w scenariuszu. W stosowanej przez nas metodyce kładziemy jednak duży nacisk na jakość samych działań programistycznych oraz uzyskiwanego kodu (m.in. dzięki zarządzaniu złożonością), co — w połączeniu ze strategią prototypowania (będącą jednocześnie dość efektywną formą testów na każdym etapie tworzenia funkcjonalności) oraz zautomatyzowanymi testami jednostkowymi — daje wysokiej jakości produkt jeszcze przed kolejnymi etapami testowania.

Głęboki monitoring

Choć zagadnienie monitorowania działających systemów może nie wydawać się bezpośrednio związane z metodyką tworzenia oprogramowania, to w przypadku naszej praktyki — jak najbardziej. Stosując metodę, którą nazywamy głębokim monitoringiem, możemy znacznie lepiej zadbać o efektywność korzystania z systemu poprzez wczesne zapobieganie problemom oraz skuteczną diagnostykę trudno reprodukowalnych błędów. Narzędzia głębokiego monitoringu opierają się na — wynikającej z naszej metodyki — możliwości ciągłego gromadzenia statystyk i szczegółów wywołania poszczególnych funkcji i procedur, implementujących małe fragmenty logiki biznesowej. Dzieje się to podczas normalnego użytkowania aplikacji w sposób całkowicie nieodczuwalny dla użytkowników. Zautomatyzowana i ciągła analiza uzyskiwanych danych ujawnia nieprawidłowości wcześniej, niż są one raportowane przez użytkowników.

Dokumentacja projektowa

Jednym z istotnych elementów zarządzania procesem developmentu jest czytelna dokumentacja projektowa, która — mimo czasem różnej formy (w zależności od zaangażowanych stron i specyfiki zagadnienia) — powinna zawierać istotną wiedzę, niezbędną do prowadzenia skutecznych działań. Zastosowanie elastycznych narzędzi (jak w naszym przypadku Enterprise Architect i Confluence) znacznie ułatwia ustrukturyzowane i scentralizowane zarządzanie dużą ilością różnego typu informacji.

Agile/Scrum

To tzw. zwinne podejście do zarządzania projektami, które stawia na elastyczność, szybkie dostosowywanie się do zmian i bliską współpracę z klientem.  Zamiast planować cały projekt z góry, praca dzielona jest na krótkie etapy (tzw. sprinty), po których dostarczany jest działający fragment produktu. Scrum to jedna z najpopularniejszych metod w ramach Agile, oparta na regularnych spotkaniach, jasnych rolach w zespole i ciągłym doskonaleniu procesu. Nasza praktyka projektowa zakłada możliwość dalszej optymalizacji procesu zarządzania — w zależności od specyfiki projektu i preferencji zaangażowanych stron.