Produkując, wdrażając i utrzymując oprogramowanie korzystamy z hybrydowej metodologii czerpiącej najlepsze wzorce z czołowych światowych metodyk.

W procesie produkcji oprogramowania – szczególnie na etapie ofertowania – nie sposób odejść od klasycznego podejścia “waterfall” (analiza, projekt, implementacja, testy wdrożenie, utrzymanie). Podejście to stosowane jest w celu określenia szacunkowych kosztów przedsięwzięcia oraz ustaleniu jego harmonogramu. Wyznaczone w ten sposób wartości stanowią fundament późniejszych ustaleń odnosząc się głównie do kamieni milowych. Na etapie ofertowania ze względu na brak dokładnej analizy i projektu systemu (wykonywanych już w ramach realizacji umowy będącej skutkiem oferty) konieczne jest odwoływanie się uogólnień oraz arbitralne rozstrzyganie niejednoznaczności i niedopowiedzeń dostępnej w tym momencie dokumentacji.

Tym niemniej już na tym etapie zakładamy, że właściwa realizacja procesu w odniesieniu do kamieni milowych realizowana będzie za pomocą metodyk zwinnych (Agile).  Pozwala to naszemu klientowi na odstępstwa od rygoryzmu planów typu waterfall. Możliwe jest tworzenie, wdrażanie i utrzymanie systemu w sposób całkowicie elastyczny tak by uwzględniać zarówno zmieniające się otoczenie biznesowe, zmiany bezpośrednich wymagań funkcjonalnych jak i nawet zmiany budżetu i harmonogramu. Agile rozumiemy jako zwinność komunikacji z klientem pozwalającą na maksymalnie dokładne dopasowanie produktu/usługi do oczekiwań klienta i jego uwarunkowań w danym punkcie czasu.

Metodologie Agile idealnie też wpasowują się w nasze firmowe DNA: utrzymanie i rozwój aplikacji jest dla nas kluczowy – w niektórych przypadkach aplikacje utrzymujemy już od ponad 20 lat. Bez zwinnego podejścia byłoby to absolutnie niemożliwe.

Fundamentem naszego podejścia do budowy oprogramowania i to już od ponad 20 lat – są mikrousługi. Tę metodologię stosowaliśmy w czasach kiedy nie miała ona jeszcze swojej nazwy. Musieliśmy więc stworzyć własne rozwiązanie w tym obszarze. Dziś – po ponad 20 latach rozwoju – jesteśmy dumni, że kierunek jaki obraliśmy stał się jednym z wiodących kierunków rozwoju dzisiejszej informatyki.

Od początku konsekwentnie rozwijamy platformę PTR “Atom” dającą niezrównane możliwości uruchamiania zarówno dziesiątek jak i setek tysięcy mikrousług.

Platforma Atom:

• radykalnie przyspiesza dewelopment przez możliwość urównoleglenia pracy programistów
• radykalnie ułatwia testowanie mikrousług
• pozwala na łatwe i elastyczne budowanie złożonych i kompleksowych usług (“związków chemicznych”) z prostych i jasno zdefiniowanych  mikrousług (“atomów”)
• posiada wbudowane mechanizmy klastrowania, monitoringu, SLA, COB, mechanizmy bezpieczeństwa itd.
• może działać w sposób zupełnie automatyczny w trybie unattended (“bez nadzoru”)

Ze względu na dość częste tworzenie oprogramowania w modelu outsourcingowym (kiedy zarówno dewelopment jak i późniejsza obsługa systemu leżą po naszej stronie) praktycznie zawsze stosujemy mechanizmy DevOps. Oznacza to w naszym przypadku:

1. Kodowanie oparte o najlepsze sprawdzone rozwiązania i technologie. Stosowanie systemów kontroli wersji (GitLab) zarówno w odniesieniu do kodu aplikacji jak i do bazy danych.

Jest to o tyle istotne, że w systemach masowej przepustowości warstwa bazodanowa jest budowana szczególnie starannie tak by zapewnić maksymalną wydajność oraz (co często jest jeszcze istotniejsze) maksymalną skalowalność. System kontroli wersji musi więc kontrolować również wersje kodu i struktury samej bazy danych

Stosujemy code review – w kluczowych elementach kodu. Jest to z jednej strony realizowane w zespole deweloperskim – ale dysponujemy też samodzielną komórką odpowiedzialną tylko za utrzymanie właściwej jakości kodu. Komórka ta odpowiedzialna jest również za kontrolę całego kodu wszystkich nowych pracowników na etapie ich adaptacji.

Konfiguracja systemu kontroli wersji oraz procedury “merge” pozwalają nam z jednej strony na niezakłócony rozwój aplikacji a z drugiej strony na bieżące realizowanie obowiązków związanych z usuwaniem błędów.

2. Continuous Building – w naszym środowisku stworzony kod źródłowy jest poddawany procesowi budowania – zarówno w kontekście artefaktów jak i samej aplikacji. Wewnętrznie, w trakcie produkcji oprogramowania, stosujemy aplikacje w wersji skonteneryzowanej. Dlatego po zbudowaniu aplikacji następuje wykreowanie obrazu kontenera(-ów) Docker oraz stworzenie pełnego środowiska w oparciu o orchestrację Kubernetes.

3. Continuous Testing – na tak stworzonym środowisku uruchamiane są mechanizmy testów automatycznych. Z jednej strony oznacza to automatyzację unit testów ale z drugiej strony są to też klasyczne testy API czy interfejsu użytkownika. Celem testów automatycznych (tworzonych przez niezależny zespół) jest realizacja zarówno testów regresji (w odniesieniu do funkcjonalności z poprzednich sprintów) jak i testów bieżącego sprinta. Co ważne – testy te realizowane są jeszcze przed skierowaniem systemu do działu testów manualnych. W efekcie potrafimy się zabezpieczyć przed zmorą wielu wdrożeń – nawracającymi błędami  pojawiającymi się podczas naprawy innych błędów.

4. Packaging/Delivery – ze względu na stosowanie konteneryzacji – wszystkie nasze rozwiązania przygotowane są jako gotowe kontenery – możliwe do pobrania przez klienta bezpośrednio z naszego wewnętrznego repozytorium. Proces aktualizacji oprogramowania staje się więc szczególnie prosty. Nawet w przypadku klientów, którzy jeszcze nie wdrożyli konteneryzacji – procesy Delivery znacząco się upraszczają.

5. Konfiguracja – ze względu na stosowanie Kubernetes (a w razie potrzeby narzędzi klasy infrastructure-as-a-code) przygotowana aplikacja jest w pełni skonfigurowana jako działający zestaw niezbędnych serwerów powiązanych z sobą. W typowym przypadku wdrożenie nowego sprinta polega u klienta na banalnej operacji odświeżenia obrazów kontenerów i ponownym uruchomieniu orchestracji Kubernetes.

6. Monitoring – tak uruchomiona aplikacja podlega ciągłemu procesowi monitoringu. Jest to szczególnie istotne w kontekście zapewnienia odpowiedniego poziomu SLA w zakresie usuwania błędów.

Użyteczność i niezawodność oprogramowania to jednak nie wszystko – dzisiejsze aplikacje powinny być także funkcjonalne, intuicyjne i ergonomiczne, dopasowane do cech użytkownika.

Dzięki wykorzystaniu metodyk projektowania zorientowanych na użytkownika oraz nowoczesnych narzędzi do budowy aplikacji WWW tworzymy dla klientów wyrafinowane, dynamiczne, w pełni interaktywne interfejsy użytkownika na najwyższym poziomie, zarazem funkcjonalne i przyjazne. Co więcej możemy budować takie aplikacje nie tylko widoczne dla przeglądarek w komputerach PC, ale również dla tabletów i innych urządzeń mobilnych. Jest to związane z tendencją jaką zauważamy by zamiast budować aplikacje mobilne sensu stricte – budować uniwersalne wersje stron WWW widoczne w specjalny sposób na urządzeniach przenośnych.

W celu zapewnienia odpowiedniej jakości oprogramowania testy wykonywane są w naszym oprogramowaniu na wielu poziomach:

• jako unit testy – tworzone bezpośrednio przez programistów w odniesieniu do wszystkich trzech warstw aplikacji
• jako testy manualne – realizowane przez Dział Testów Manualnych
• jako testy automatyczne  – realizowane przez Dział Testów Automatycznych a przekazywane do Działu Deweloperskiego

Mechanizm tzw. unit testów oznacza, że wszystkie nasze aplikacje są wyposażone w specjalizowane funkcje testujące poprawność pojedynczych małych jednostek oprogramowania. Dla każdego zlecenia programiści tworzą specjalne procedury testowe, które następnie są wykonywane w sposób całkowicie automatyczny. W efekcie osiągnęliśmy zdecydowaną poprawę jakości oprogramowania poprzez automatyzację testów regresji – sprawdzenie czy błąd jaki już kiedyś występował i został naprawiony – nie pojawił się ponownie.

Stosując mechanizm testów bazy danych automatyczne badamy jakość procedur składowanych w bazie danych. Procedury te stanowią fundament na którym budowana jest reszta aplikacji – dlatego używamy narzędzi które w sposób zautomatyzowany są w stanie przeprowadzić gigantyczną liczbę testów i zbadać poprawności wykonania procedur składowanych, nawet przy najdrobniejszych zmianach. Testy na tym poziomie można rozumieć jako testy warstwy bazy danych w klasycznej trójwarstwowej architekturze aplikacji.

Dopełnieniem procesu testów jest mechanizm testowania interfejsów programistycznych do aplikacji (REST). Oznacza to, że nim przeprowadzimy testy interfejsu użytkownika automatycznie sprawdzamy poprawność interfejsów programistycznych (wywołujących procedury składowane i wykorzystujących unity aplikacji testowane na poziomie unit testów). Testy na tym poziomie można rozumieć jako testy warstwy biznesowej.

Powyższe mechanizmy testów łączymy z testami intrerfejsu użytkownika dla aplikacji WWW wykonywanymi przez dział testów wykorzystujący w tym celu m.in. oprogramowanie Selenium/Katalon będące zestawem narzędzi służących do zapisywania scenariuszy testowych a następnie ich automatycznego wykonywania przy każdej najdrobniejszej modyfikacji aplikacji, nawet jeśli z pozoru dana modyfikacja wydaje się nie mieć jakiegokolwiek związku z innymi elementami aplikacji.

Wdrożyliśmy rozwiązanie pozwalające na automatyczne wykonywanie nie tylko procesu budowania aplikacji z przygotowanych przez programistów kodów źródłowych, ale nade wszystko na automatyczne wykonanie wszystkich testów powyżej (Continuous integration).

Celem jest aby każda kolejna – nawet minimalna poprawka dowolnego fragmentu kodu źródłowego aplikacji powodowała automatyczne wykonanie wszystkich automatycznych testów: testów jednostkowych, testów bazy danych (procedur składowanych), testów warstwy biznesowej  i testów interfejsu użytkownika.

Testy powyższe, w zależności od swojego położenia w procesie, mogą w szczególności stanowić testy regresji (poprzez test w danym sprincie realizacji funkcjonalności już zrealizowanych w sprintach poprzednich), testy akceptacyjne – lub dowolny inny rodzaj testów.

W celu zapewnienia maksymalnej jakości oprogramowania Dział Deweloperski, Testów Manualnych oraz Dział Testów Automatycznych są niezależne od siebie. Współdzielone są natomiast scenariusze testowe – tak by zapewnić maksymalnie pokrycie aplikacji testami. Scenariusze testowe są ściśle zdefiniowane. Dzięki temu wszystkie wspomniane zespoły mogą efektywnie wpływać na jakość finalnej aplikacji.

Testy, ze względu na oczekiwaną wysoką jakość oprogramowania, stanowią centralny element całego procesu. Wychodząc z metodologii TDD (Test Driven Development) stosujemy zmodyfikowane BDD (Behaviour Driven Development). “Zmodyfikowane” bo uważamy, że nie jedynie sam proces wytwórczy oprogramowania powinien być podporządkowany oczekiwanemu zachowaniu systemu. Naszym zdaniem wszystkie procesy wiążące dostawcę oprogramowania z klientem powinny być temu podporządkowane.

Dlatego wolimy mówić o Behaviour Driven Relation (BDR).

W BDR zakładamy, że całość relacji pomiędzy nami – jako dostawcą – a klientem powinna skupiać się na konkretnych oczekiwanych przez klienta funkcjonalnościach/zachowaniach aplikacji. Co więcej – wymagania te powinny być sformułowane w najbardziej zrozumiałym dla niego języku biznesowym. Stanowi to czytelne odniesienie do wizji DDD (Domain Driven Design).

Z wieloletniego doświadczenia wynika, że zazwyczaj klientowi zdecydowanie łatwiej przychodzi opisanie konkretnych przykładów działania aplikacji niż zdefiniowanie jej dokładnego funkcjonowania jak się to dzieje w “klasycznej” analizie. Takie przykłady działania systemu z jednej strony mogą stanowić doskonały wsad do produkcji oprogramowania, specyfikację testu (manualnego czy automatycznego), a nawet mogą stanowić rewelacyjne uzupełnienie dokumentacji (gdyż stworzone są w języku i przy pomocy pojęć zrozumiałych dla klienta).

Powyższe oznacza, że już na etapie specyfikowania wymagań danego systemu, czy też węziej – kamienia milowego, sprinta czy wręcz pojedynczej funkcjonalności – określamy zachowanie się systemu – np. za pomocą notacji Gherkin. Świadomość jak powinna zachowywać się aplikacja – już na etapie analizy/projektu – zupełnie inaczej ustawia cały proces przeprowadzania rozmów i ustaleń z klientem. Radykalnie zmienia to relację z nim – rozmowy dotyczą nie tyle pojedynczej dostawy – co konkretnej funkcjonalności, konkretnego zachowania jakiego z biznesowego punktu widzenia klient oczekuje. Rozmowy te prowadzone są nie tylko w typowym dla inżynierii oprogramowania języku opartym o “deliverables”, “sprinty”, “backlog” ale nade wszystko w języku opisującym konkretne efekty jakie klient chce osiągnąć przy pomocy aplikacji.

Efektem tego jest zmiana typowej relacji dostawca-odbiorca w relacje partnerska w której obie strony skupiają się na zachowaniu systemu a tym samym jego jakość stawiana jest na pierwszym miejscu w liście priorytetów.

W celu zapewnienia właściwej koordynacji prac – przy mnogości spraw realizowanych w każdym projekcie – od wielu lat konsekwentnie stosujemy rozwiązania światowego lidera – firmy Atlassian:

• Jira – jest naszym kluczowym systemem do definiowania zleceń, kontroli procesu realizacji, nadzoru nad właściwym workflow, definiowania wymagań a nawet do komunikacji z klientem na etapie zgłaszania uwag i rozwoju systemu. Jira służy nam do kompleksowego  zarządzania projektami, umożliwiając nam jednocześnie terminową realizację poszczególnych zleceń o najwyższej jakości
• Confluence – jest naszym kluczowym system do tworzenia, przechowywania i udostępniania wiedzy. Dotyczy to zarówno wiedzy na temat danego systemu (tak tworzymy i aktualizujemy różnego rodzaju dokumentacje) jak i wiedzy operacyjnej (procedury współpracy, wewnętrzne regulacje itd). Jest to specjalizowany collaboration serwer za pomocą którego grupy projektowe mogą tworzyć i współdzielić dokumentacje, wymieniać się pomysłami oraz wiedzą. Efektem wdrożenia jest wewnętrzny portal służący do przechowywania dokumentacji oraz wymiany wiedzy w związku z realizacją konkretnych zleceń dla klientów z dokładnością do pojedynczej sprawy i jej historii.

Oba narzędzia uzupełnione są zestawem pluginów uzupełniających funkcjonalność o niezbędne elementy (np. rozliczanie czasu pracy, definiowanie testów itp.)

Naszym Klientom oferujemy pełną opiekę nad zrealizowanym i wdrożonym systemem, w tym:

• Gotowość do świadczenia i świadczenie usług gwarancyjnych polegających na usuwaniu błędów i wsparciu technicznym dla systemu
• Gotowość do świadczenia wszelkich usług pogwarancyjnych w celu modyfikacji i rozwoju systemu.
• Chcąc zapewnić naszym Klientom transparentność oraz najwyższą jakość obsługi serwisowej udostępniamy, zintegrowany z Jira, niezwykle intuicyjny internetowy system ticketowy dmt@work, który umożliwia nie tylko rejestrację i śledzenie realizacji danego zlecenia lecz także dwustronną wymianę informacjami, spostrzeżeń i uwag związanych z daną sprawą na dowolnym z etapie jej realizacji. dmt@work spełnia zatem w naszej firmie rolę interaktywnej i dynamicznej platformy do codziennej współpracy oraz przepływu informacji pomiędzy zespołem dmt a naszym Klientem.